Why GitHub Copilot Login Hangs When Clash Is Running

GitHub Copilot login timeout is often described as a Copilot problem, but the failure may occur in several different network stages. Visual Studio Code can open a browser window, GitHub can display the authorization page, and your normal websites can load while the editor still waits forever for the callback or token exchange. When Clash is active, those operations may take different routes, use different DNS answers, or bypass the proxy entirely.

Copilot is not a single website request. Depending on the editor and extension version, sign-in can involve github.com, api.github.com, GitHub OAuth endpoints, GitHub asset or extension services, and Copilot API hosts such as api.githubcopilot.com or copilot-proxy.githubusercontent.com. The exact host list can change, so copying a rule set from an old tutorial is less reliable than checking Clash’s live connection log while reproducing the failure.

The most common pattern is an inconsistent route. Your browser reaches GitHub through the selected Clash proxy, but the callback received by VS Code is handled by a direct process connection. In another case, the browser uses a proxy while the Copilot extension opens its own HTTPS connection and matches a broad GEOIP or FINAL rule. A third possibility is that the connection is proxied correctly but the selected node cannot maintain a stable TLS session to GitHub’s API or Copilot service.

Before changing advanced settings, note the exact symptom. Does the browser never open? Does GitHub authorization complete but VS Code remain on “Signing in”? Does login succeed while inline suggestions show “Failed to connect”? Or does Copilot work for a few minutes and then stop? Each symptom points to a different part of the path, and changing DNS or enabling TUN mode without identifying the failing stage can make troubleshooting harder.

Check the Active Clash Profile, Mode, and Proxy Path

Start with the least invasive check: confirm that Clash is actually running the profile you think it is. A profile may have been updated recently, switched to a different proxy group, or left in Direct mode after a previous test. Open the Clash dashboard and verify the active configuration, the current mode, and the group selected for GitHub-related traffic.

1. Confirm the client is running: Check that the Clash tray icon or desktop dashboard reports an active core rather than a stopped service or failed configuration.
2. Check the operating mode: Use Rule mode for normal split routing, and temporarily test Global mode only as a diagnostic comparison. Do not treat Global mode as the permanent solution.
3. Inspect the proxy group: Select a known-working node or a stable selector group instead of an automatic group that may be switching during authentication.
4. Verify the listener: Note the local HTTP or mixed port, commonly represented by a value such as 7890, but use the port shown by your own profile rather than assuming a default.
5. Reproduce one action at a time: Start the GitHub login flow, watch the connection list, and record the hostnames, matched rules, outbound group, and connection result.

In Rule mode, search the live connection view for terms such as github, copilot, oauth, and visualstudio. A connection marked DIRECT is not automatically wrong; GitHub may be reachable directly on one network. The useful question is whether the result is consistent with your intended policy. If the browser authorization request goes through a proxy but the extension API request is direct, the login can complete only partially.

Global mode is useful because it removes most rule-order uncertainty. If Copilot signs in immediately in Global mode, the node and basic transport are probably usable, and your Rule mode configuration deserves attention. If Global mode also fails, investigate the node, TLS behavior, account status, local firewall, and system clock before writing more domain rules.

Avoid testing with several clients at the same time. Clash Verge Rev, Mihomo Party, a legacy Clash client, a VPN application, and a corporate security agent can each install listeners or virtual adapters. The browser may use one proxy while VS Code uses another, producing misleading results. Close competing clients, disable a second VPN temporarily, and repeat the same login attempt with one active Clash core.

Test the Node and Separate Browser OAuth From Copilot API Traffic

Once the active path is visible, test the selected node rather than judging it by latency alone. A node can return a fast ping result and still fail GitHub’s TLS handshake, reset long-lived HTTPS connections, or route large responses poorly. Copilot needs more than a quick speed-test page: authentication requires several redirects and API calls, while suggestions depend on repeated requests that may remain open for longer than a simple web check.

Use a normal browser to open GitHub and sign in, but do not stop there. In a separate test, open the GitHub account or settings page and confirm that it loads through the same expected Clash outbound. Then launch the Copilot sign-in flow from your editor. Watch whether the following sequence appears: browser authorization, callback to the local editor, token exchange, extension activation, and finally a Copilot service request. If the browser succeeds but no Copilot-related connection appears in Clash, the extension process is not using the path you assumed.

On Windows, Visual Studio Code may inherit system proxy settings, but extensions and child processes can behave differently depending on the editor build and configuration. On macOS and Linux, a terminal-launched editor may inherit environment variables that differ from the graphical application. Check the editor’s proxy settings and, when appropriate, compare them with the Clash mixed port. A stale manual proxy entry can point to an old port, while a malformed value can prevent the extension host from making outbound requests.

For a temporary diagnostic, set the editor’s HTTP proxy to the local Clash mixed port in the format shown below, replacing the port with your actual listener:

http://127.0.0.1:7890

Do not leave multiple conflicting proxy mechanisms enabled without a reason. If the editor has a manual proxy, the operating system has a system proxy, and the Clash client is also using TUN capture, you may create a chain where one request is proxied twice or sent to an unavailable listener. Test one arrangement, record the result, and then return to the configuration that matches your normal workflow.

Also check the system clock and certificate environment. OAuth tokens and TLS certificates depend on reasonably accurate time. A machine several minutes out of sync can show a generic authentication failure that resembles a proxy timeout. Corporate antivirus, endpoint inspection, and DNS filtering products can intercept GitHub certificates or block unknown Copilot endpoints. If the connection log shows a reset immediately after TLS negotiation, temporarily compare the result with the security product paused according to your organization’s policy.

Fix Domain Rules Before Enabling TUN Mode

If Global mode works but Rule mode does not, improve the rules instead of immediately enabling every advanced feature. A practical policy should route the domains observed during your own test through a stable proxy group and place those rules above broad geographic, keyword, or final rules. Depending on the editor version, provider, and current service architecture, the relevant destinations may include github.com, api.github.com, githubusercontent.com, githubassets.com, githubcopilot.com, and specific Copilot proxy hosts. Do not blindly proxy every GitHub-related domain if your organization requires a narrower policy.

For a local diagnostic override, the structure may look like this:

rules:
  - DOMAIN-SUFFIX,github.com,COPILOT
  - DOMAIN-SUFFIX,githubusercontent.com,COPILOT
  - DOMAIN-SUFFIX,githubassets.com,COPILOT
  - DOMAIN-SUFFIX,githubcopilot.com,COPILOT
  - DOMAIN-SUFFIX,api.github.com,COPILOT
  - MATCH,DIRECT

This is only a starting example. The group name must exist in your configuration, and a provider’s rule provider may be loaded before or after local rules depending on the client. Verify the effective configuration in the dashboard. If an earlier rule already matches github.com, adding a later rule will have no effect. Rule order matters more than the number of lines.

Be careful with GEOIP, IP-CIDR, and fake-IP behavior. A hostname may resolve to an address that looks local or belongs to a CDN range, allowing a broad IP rule to win before the intended domain rule. In fake-IP mode, confirm that the DNS mapping and redirection path are compatible with the Mihomo core and the operating system. In redir-host mode, verify that the resolved address does not make your rule logic unexpectedly bypass the proxy.

DNS should be changed only when evidence points to DNS. Useful clues include a hostname resolving to an unusable address, different results between browser and editor, or a connection log that shows an unexpected destination before the TLS request. A reasonable test is to use Clash’s built-in DNS handling consistently and compare the result with the current system resolver. Avoid mixing several encrypted DNS applications, browser Secure DNS, router DNS rewriting, and Clash fake-IP settings during the same test; you will not know which layer produced the answer.

After changing rules, clear stale editor state carefully. Sign out of GitHub inside the editor, close all editor windows, restart Clash, and then launch the editor again. You can also reload or reinstall the Copilot extension if its local state is damaged, but do this after the network path is stable. Otherwise, a broken profile and a broken authentication cache can hide each other and make the same timeout return after every restart.

When TUN Mode Helps, and When It Does Not

TUN mode is useful when the application does not honor system proxy settings or when the editor and extension host open raw sockets that never reach the HTTP listener. It creates a virtual network interface and lets the Clash core capture traffic at a lower level. This can make Copilot behavior more consistent across Visual Studio Code, JetBrains IDEs, GitHub Desktop, terminal tools, and background extension processes.

TUN mode is not a magic repair for a dead node or an incorrect rule. If the selected outbound cannot reach GitHub, TUN simply captures the request and sends it through the same failing route. It also introduces additional variables: administrator permission, a virtual adapter, DNS hijacking, route priority, IPv6 handling, and possible conflicts with another VPN. Use it after confirming that the basic proxy route is healthy.

1. Stop competing tunnels: Disable other VPN clients, virtual adapters, and traffic-capture tools for the test.
2. Enable TUN with the default recommended settings: Avoid changing stack, DNS, auto-route, and strict-route options simultaneously.
3. Approve the required permission: On Windows this may require administrator approval; on macOS or Linux, allow the network extension or service helper requested by the client.
4. Restart the editor: A process that started before TUN was active may retain old proxy or DNS behavior.
5. Repeat the login and inspect connections: Confirm that the relevant GitHub and Copilot hosts are captured and match the intended rule.

If TUN fixes the login but breaks other applications, narrow its scope or review DNS and route settings instead of keeping an unstable configuration. IPv6 is another useful comparison: if connections repeatedly fail on IPv6 while IPv4 works, temporarily test with IPv6 handling disabled or explicitly routed, depending on your network and Clash client. Do not treat that temporary test as a universal recommendation; the correct choice depends on your ISP, router, operating system, and profile.

Once sign-in works, test more than the account badge. Open a small source file, request an inline completion, trigger a chat request if your extension provides one, and wait several minutes. Watch for repeated connection resets or group changes. An automatic URL-test group may select a different node after login, causing a token request to succeed and the first completion request to fail. A stable selector is often better for diagnosis than a rapidly changing fallback group.

Finally, collect useful logs before asking for support. Record the editor version, Copilot extension version, Clash client and core version, operating system, profile mode, selected group, and the first failing hostname. Redact subscription URLs, authorization codes, access tokens, cookies, and private source code. A message such as “Copilot timeout” is difficult to act on; “browser OAuth succeeds, api.githubcopilot.com matches DIRECT, and Global mode works” immediately identifies a rule problem.

GitHub Copilot and Clash FAQ

Why does GitHub open normally while Copilot still fails?

GitHub web traffic and Copilot extension traffic may use different hostnames, processes, and proxy behavior. Your browser can follow the system proxy while the editor extension host uses a manual setting, environment variable, or direct socket. Check the Clash connection log during an actual completion request, not only while opening the GitHub homepage. If the Copilot host is missing or marked DIRECT, adjust the effective rule or editor capture path.

Why does Global mode fix the login but Rule mode does not?

Global mode sends nearly everything through the selected outbound, while Rule mode depends on rule order and DNS classification. A broad DIRECT, GEOIP, or provider rule may match before your GitHub rule. Compare the matched rule for each failing hostname and place a narrow, intentional rule above the broad fallback. Keep Global mode as a test result rather than a permanent workaround if you need local services to remain direct.

Do I need TUN mode to use GitHub Copilot with Clash?

No. If the editor respects the system proxy or a correctly configured local HTTP or mixed port, normal system proxy mode is enough. TUN mode becomes useful when the extension host bypasses that listener, when several applications need one consistent capture path, or when raw socket behavior prevents the manual proxy from working. Enable it only after checking permissions, route conflicts, and DNS behavior.

What if Copilot logs in but keeps disconnecting?

Check node stability, group switching, TLS resets, and long-lived connection behavior. A fast latency result does not guarantee a reliable Copilot session. Pin a known-good node temporarily, verify that the relevant hosts use the same intended group, and test without another VPN or endpoint inspection layer. If every network and node produces the same result, check the editor extension state, GitHub account entitlement, service status, and sanitized extension logs.

Some competing proxy clients make this workflow unnecessarily opaque: browser-only proxy extensions can leave the editor untouched, legacy Clash builds may not understand current Mihomo profile features, and all-in-one VPN tools often hide the matched rule and destination that you need for diagnosis. Clash Official Site is more useful here because its profile, connection log, rule order, proxy group, and optional TUN path can be checked as separate layers rather than guessed from a single “connected” indicator. If you want a current Clash client for reproducing the steps above with visible routing controls, you can download Clash Official Site and test the GitHub Copilot login path methodically.