Fix GitHub Copilot Not Working With Clash: Troubleshoot Access

GitHub Copilot can appear to be installed correctly while remaining unusable: sign-in may loop, completions may never arrive, chat may show a network error, or the extension may stay silent inside VS Code and JetBrains IDEs. When Clash is running, the cause is often not the Copilot extension itself. Traffic may be sent through an unsuitable node, matched by a direct rule, resolved by the wrong DNS server, or captured inconsistently by TUN mode. This guide explains how to fix GitHub Copilot not working with Clash by isolating the proxy, rule, DNS, node, and editor layers one at a time.

Understand the GitHub Copilot Connection Path

Before changing settings randomly, it helps to understand what must work. GitHub Copilot is not a single website request. The editor extension usually communicates with several GitHub and Microsoft service endpoints for authentication, token exchange, completion requests, chat features, telemetry, and extension updates. A browser may open GitHub successfully while Copilot still fails because the editor uses a different runtime, a different proxy setting, or a different set of domains.

In a typical desktop setup, the request path looks like this:

1. The VS Code or JetBrains Copilot extension starts an authentication or completion request.
2. The editor decides whether to use its own proxy configuration, the operating system proxy, or a direct connection.
3. Clash receives the connection through the system proxy, a transparent redirection mode, or TUN interception.
4. Clash resolves the destination domain, matches it against rules, and selects a proxy group.
5. The selected node establishes a TLS connection to the GitHub or Copilot service.
6. The response returns to the editor, which must also accept the certificate and maintain the session.

A failure at any stage can produce a vague message such as “Copilot is taking longer than expected.” For that reason, first identify the exact symptom rather than treating every problem as a general Clash outage.

Keep the Clash dashboard open while reproducing the problem. In the Connections view, search for terms such as github, copilot, api, or vscode. If no relevant connection appears, the request is probably bypassing Clash or being blocked before it reaches the proxy. If the connection appears and is marked failed, the problem is more likely related to the rule, DNS result, node, TLS handshake, or remote service.

Check Clash Rules and Proxy Groups

The most common Clash-related cause is a rule that sends Copilot traffic directly or to a proxy group containing an unhealthy node. A general rule such as GEOIP,CN,DIRECT is not enough to guarantee correct routing, because an endpoint may resolve to an address that does not reflect its service location. Likewise, a rule provider can match a GitHub domain earlier than your intended rule and override the result.

Clash processes rules from top to bottom. The first matching rule wins. Put specific GitHub and Copilot rules above broad geographic, private-network, or final rules. A practical starting point for a Mihomo-compatible configuration is:

rules:
  - DOMAIN-SUFFIX,github.com,GitHub-Copilot
  - DOMAIN-SUFFIX,githubusercontent.com,GitHub-Copilot
  - DOMAIN-SUFFIX,githubassets.com,GitHub-Copilot
  - DOMAIN-SUFFIX,githubcopilot.com,GitHub-Copilot
  - DOMAIN-SUFFIX,github.com,GitHub-Copilot
  - MATCH,Final

proxy-groups:
  - name: GitHub-Copilot
    type: select
    proxies:
      - Auto-Select
      - node-us-01
      - node-jp-01
      - DIRECT

The exact endpoint list can change as GitHub and Microsoft update their architecture, so do not assume that one domain covers every Copilot feature. Inspect the Clash connection log while signing in and while requesting a completion. Add only domains that you have observed or that are documented for the feature you use. Avoid broad rules such as DOMAIN-SUFFIX,microsoft.com unless you understand the side effects, because they may proxy unrelated services and increase latency.

When a proxy group uses url-test, the health-check URL may be reachable even though the node cannot reliably connect to GitHub or Copilot. A low latency number is not proof of application compatibility. Test several nodes manually and compare authentication, completion, and chat separately. Some nodes handle ordinary HTTPS well but fail on long-lived connections, HTTP/2 behavior, WebSocket-like traffic, or the service’s regional routing.

Also check whether a rule provider has become stale. Update providers, reload the configuration, and clear old connections. If the dashboard offers a rule hit-test function, enter the exact hostname and confirm that the result is the intended proxy group. In Clash Verge or Clash Verge Rev, configuration changes may require selecting the active profile and reloading it; editing a downloaded subscription file without activating it will not change live traffic.

Perform a Clean Copilot Connectivity Test

Now perform a short, repeatable test instead of trying every editor feature at once. This procedure works across Clash Verge, Clash Verge Rev, Mihomo-based clients, and most desktop Clash front ends.

1. Close VS Code or JetBrains completely. Make sure no background editor process remains in Task Manager, Activity Monitor, or the equivalent process viewer.
2. Open Clash and confirm that the intended profile is active. Verify that the mixed port or HTTP proxy port is listening and that the selected proxy group has a working node.
3. Disable TUN mode temporarily. Leave the system proxy enabled if your client supports it, then test the browser and the editor through the ordinary HTTP or SOCKS proxy path.
4. Select one stable node manually. Do not begin with automatic load balancing, fallback switching, or a large rule provider.
5. Reload the Clash profile and clear existing connections. Old failed TLS sessions can make a new configuration appear ineffective.
6. Start the editor and open its account or Copilot status panel. Watch the Clash connection list while signing in.
7. After sign-in succeeds, open a small source file and type a simple function or comment. Wait for an inline suggestion, then check which new domains appear in the connection log.
8. Test Copilot Chat separately if you use it. Chat can depend on additional endpoints and may fail even when inline completions work.

# Replace 7890 with the HTTP or mixed port used by your Clash client
curl -I -x http://127.0.0.1:7890 https://github.com
curl -I -x http://127.0.0.1:7890 https://api.github.com

A successful response from github.com proves only that the proxy can reach GitHub’s main site. It does not prove that the Copilot service is available. The useful comparison is between three states: direct connection, browser through Clash, and editor through Clash. If the browser succeeds but the editor fails, concentrate on editor proxy and certificate settings. If both browser and editor fail, inspect Clash rules, DNS, and the node. If only TUN mode fails, focus on routing and DNS interception.

Fix DNS and TUN Mode Conflicts

DNS becomes especially important when Copilot is used with TUN mode. In fake-IP mode, Clash returns a synthetic address to the application and keeps the domain mapping internally. This allows domain rules to run before the real destination IP is known. In redir-host mode, the application receives a real address, so IP-based routing and local DNS behavior can affect the result more directly.

If Copilot works with the system proxy but stops working when TUN is enabled, compare these settings first:

A common mistake is running a VPN, another proxy application, and Clash TUN mode at the same time. Each tool may install routes, DNS redirection, or virtual adapters. The result can be a loop, a route leak, or a connection that leaves through the wrong interface. Disable other network tools during testing. On Windows, check whether another application has changed the system proxy or installed a competing Wintun or TAP adapter. On macOS and Linux, inspect active proxy environment variables and virtual interfaces.

For a clean test, keep DNS handling inside Clash, use a consistent fake-IP filter if your configuration requires one, and make sure private domains such as localhost, *.local, and internal company hosts are not sent to an external proxy. If a corporate network provides its own DNS or TLS inspection, do not blindly replace its certificate chain; instead, determine whether the organization requires a trusted root certificate or an approved proxy endpoint.

IPv6 is another frequent source of confusing results. The browser may prefer IPv4 through Clash while the editor attempts an IPv6 connection outside the expected route. Temporarily disable IPv6 in the Clash profile or operating system only as a diagnostic step. If that fixes Copilot, restore IPv6 later and configure a consistent IPv6 policy rather than leaving the system in a partially disabled state.

Configure VS Code and JetBrains Correctly

VS Code and JetBrains IDEs do not always inherit proxy settings in the same way. A system proxy can be visible to one application while another uses its own HTTP client, environment variables, or embedded runtime. This is why “GitHub works in my browser” is not sufficient evidence.

In VS Code, open Settings and search for proxy. Review the HTTP proxy value, proxy support mode, and strict SSL setting. If Clash is already configured as the operating system proxy, avoid adding a second proxy URL unless the editor clearly requires it. A duplicate configuration can create a proxy loop or cause GitHub authentication to use a different route from Copilot requests. If you use a local Clash HTTP port, the value commonly resembles:

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": true
}

Use that example only when the port matches your Clash client. Keep http.proxyStrictSSL enabled in normal use. Disabling certificate verification may hide the real problem and weakens the security of every extension connection. If strict SSL fails, inspect the system clock, certificate chain, antivirus HTTPS inspection, and corporate root certificate installation instead of leaving verification disabled.

Open View → Output, select GitHub Copilot from the output channel, and inspect the first error after reproducing the issue. Also check Help → Toggle Developer Tools when the extension reports an unexpected network failure. Look for DNS errors, connection resets, proxy authentication failures, certificate errors, and HTTP status codes. A 401 or 403 points toward authentication or account policy; a timeout or reset points more strongly toward the route, node, or proxy.

In JetBrains IDEs, open Settings → Appearance & Behavior → System Settings → HTTP Proxy. Test the connection using the configured Clash HTTP port, and decide whether the IDE should use the system proxy or a manual proxy. Do not configure both paths unless the documentation for your environment specifically requires it. JetBrains also uses its own runtime, so certificate trust can differ from the browser and operating system. If the IDE reports an SSL handshake or unknown certificate error, import the organization’s legitimate root certificate into the appropriate trust store and verify that Clash is not performing unexpected TLS interception.

After changing editor settings, restart the IDE rather than only disabling and re-enabling the extension. Authentication callbacks, extension processes, and embedded network clients may keep old proxy values until the process exits. Sign out of GitHub Copilot only after confirming that the proxy path is stable; repeated sign-in attempts can invalidate temporary sessions and make diagnosis harder.

Interpret Errors and Apply the Right Fix

Use the error category to choose the next action. Do not replace the entire configuration because of one failed request. The following patterns are especially useful:

• Connection refused to 127.0.0.1: the editor is pointing to the wrong Clash port, or Clash is not running. Confirm the HTTP or mixed port and test it with curl.
• Proxy authentication required: the local proxy may have a username and password configured, or the editor may be sending credentials intended for a remote proxy. Check the Clash client’s local authentication settings.
• DNS_PROBE_FINISHED_NXDOMAIN or name resolution failure: inspect Clash DNS mode, upstream resolvers, fake-IP settings, and competing VPN DNS services.
• ETIMEDOUT, ECONNRESET, or handshake timeout: switch to a known-good node, test another transport, and check whether the current node supports stable HTTPS connections.
• 401 or repeated sign-in prompts: refresh authentication, check system time, and ensure that the browser callback is returning to the correct editor instance.
• 403 or policy-related response: verify account entitlement, organization policy, regional availability, and GitHub Copilot status. A proxy cannot fix an account restriction.
• Inline completion works but chat fails: inspect additional chat-related connections and confirm that your editor and Copilot extension are current.

Once the basic path works, re-enable features one by one: automatic node selection, rule providers, TUN mode, IPv6, and other VPN software. After each change, test both sign-in and a completion request. This identifies the exact change that reintroduces the failure and gives you a configuration you can maintain instead of a collection of unverified workarounds.

Finally, keep Clash, Mihomo-compatible clients, VS Code or JetBrains, and the Copilot extension updated from trusted sources. Configuration keys and service endpoints can evolve, and an old client may mishandle newer TLS or HTTP behavior. Export a working profile before making major changes, remove temporary debug rules after testing, and document the selected node, proxy port, DNS mode, and editor setting. A small record makes future troubleshooting much faster.