Start with the symptom and the network layer
GitHub Copilot timeouts in Clash are not always caused by an unavailable proxy node. Copilot depends on several separate connections: account authentication through GitHub, communication with Copilot service endpoints, editor extension requests, and sometimes a persistent streaming or WebSocket-style connection. A browser can open GitHub successfully while the editor still reports “timed out,” “failed to connect,” or “no suggestions.” The browser may be using a different proxy path, DNS resolver, certificate store, or authentication session.
Before changing multiple Clash settings, write down the exact symptom, the editor, the operating system, the active client, and the time of the failure. “Sign-in failed,” “Copilot is unavailable,” “suggestion timed out,” and “extension activation failed” point to different stages. Also note whether ordinary HTTPS sites work through the same policy group. If every website fails, start with the core, port, and node. If GitHub works but Copilot alone fails, inspect rules, endpoint routing, DNS, and application proxy behavior.
| Observed symptom | Most likely layer | First check |
|---|---|---|
| Clash shows no active connection | Editor is not using the system proxy or TUN | System proxy settings, editor proxy settings, and TUN state |
| GitHub opens, but sign-in cannot finish | Authentication callback, browser session, or blocked endpoint | Browser login, callback window, and Clash connection log |
| Sign-in works, but suggestions time out | Copilot service routing, WebSocket-like streaming, or node quality | Copilot-related domains and the selected policy group |
| Suggestions appear only after enabling TUN | The editor bypasses the system proxy | Editor proxy support and TUN route mode |
| Timeout occurs only on one node | Node congestion, filtering, or protocol incompatibility | Switch to another node in the same policy group |
Identify the client, core, and active port
Clash clients such as FlClash, Clash Verge Rev, ClashX, and Clash for Android provide the interface, but the core performs DNS resolution, rule matching, proxy connection establishment, and traffic forwarding. First open the client’s general settings or runtime information and confirm that the core is running. Then check the current mixed port. A common value is 7890, but the real value may be different. A browser or editor configured for 127.0.0.1:7890 cannot reach a core listening on 127.0.0.1:7897.
A minimal local test can distinguish a dead port from a bad remote route. Replace the port if your client uses another value:
curl -I --proxy http://127.0.0.1:7890 \
--connect-timeout 10 \
--max-time 20 \
https://github.com/A response such as HTTP/2 200, 301, or 302 proves that the local HTTP proxy accepted the request and that at least one HTTPS route is working. “Connection refused” usually means that the core is stopped or the port is wrong. A timeout after the proxy accepts the request points further downstream to DNS, the selected node, a rule, or the destination service. This test does not prove that every Copilot endpoint works, but it prevents troubleshooting an editor before the local proxy is functional.
Verify the node and Copilot routing
Copilot requests should not be sent through a policy group that is unstable, blocked, or configured to select a node with a misleading latency result. A node can answer a small ICMP or HTTP probe quickly while failing on longer HTTPS requests, certificate negotiation, HTTP/2 streams, or sustained response traffic. Open the Clash client’s proxy or connections view, select a known reliable node, and repeat the sign-in or suggestion test. Do not judge a node only by the displayed delay.
Use the Clash connection log while reproducing the error. Search for domains containing GitHub or Copilot-related names, but do not assume that one fixed hostname represents the entire service. GitHub changes service infrastructure and endpoint routing over time. The important evidence is the domain actually shown in the current log, the matched rule, the selected policy, and whether the connection ends with an error.
| Log evidence | Interpretation | Useful action |
|---|---|---|
Matched DIRECT and then timed out |
The request bypassed the proxy | Add a narrow domain rule or test with a temporary proxy policy |
| Matched a proxy group but no node connection appears | The group may be empty, paused, or unable to select a member | Choose a concrete working node and inspect group health checks |
| Repeated connection resets | The node, transport, or upstream network is interrupting the session | Test another node and compare protocol types |
| DNS error before a connection is created | The hostname was not resolved correctly | Review Clash DNS mode, fake-IP behavior, and upstream resolvers |
| Successful connection followed by editor timeout | The request started but the application did not receive a usable response | Check application proxy support, streaming behavior, and node stability |
Use a temporary specific rule for testing
For diagnosis, place the relevant GitHub and Copilot service domains in a dedicated policy group rather than sending all traffic through the same route. A temporary rule can tell you whether the normal rule set is making the wrong decision:
rules:
- DOMAIN-SUFFIX,github.com,Copilot-Test
- DOMAIN-SUFFIX,githubusercontent.com,Copilot-Test
- DOMAIN-SUFFIX,copilot.com,Copilot-Test
- MATCH,FinalThe exact destination domains depend on the editor extension, service generation, and current GitHub infrastructure. Do not copy a domain list from an old post and treat it as permanent. Confirm each hostname in the live Clash log, then add only the domains that are actually required. If a rule provider is used, check whether its rules are stale or loaded after a broad GEOIP, GEOSITE, or MATCH rule. Clash evaluates rules from top to bottom, so a broad rule placed earlier can prevent a later Copilot rule from ever being reached.
After saving the temporary rule, reload the configuration or restart the core, clear any stale connection entries, and perform one controlled test. If the request now uses the expected policy group, the issue is routing rather than the editor account. Once the cause is confirmed, replace the temporary rule with the smallest maintainable rule set. Avoid routing every GitHub-related domain through a special group without checking the effect on package downloads, source control, and other development services.
Fix DNS, TLS, and editor proxy behavior
DNS problems often look like proxy timeouts. If the hostname resolves to an unreachable address, resolves inconsistently between IPv4 and IPv6, or is intercepted by a local network filter, the selected node may never receive a usable connection. In the Clash client, compare the result with and without the configured DNS mode. mihomo-based clients may use enhanced mode, fake-IP, redirection, or nameserver policies; the correct choice depends on the operating system and whether TUN is enabled.
Do not randomly add public DNS servers as a first response. Confirm the failure in the Clash log and test one resolver change at a time. A practical sequence is to use a stable HTTPS-capable upstream resolver, keep the resolver policy consistent with the proxy route, and then flush the operating system DNS cache if the platform has retained a failed result. If fake-IP is enabled, make sure the relevant domains are not incorrectly listed in fake-ip-filter. If a domain is excluded from fake-IP while the application expects transparent routing, its traffic may follow a different path from other Copilot requests.
Check the editor-specific proxy setting
Visual Studio Code and other development environments may use their own proxy settings, environment variables, or extension-specific networking behavior. A system proxy toggle in Clash does not guarantee that every editor extension will use it. In Visual Studio Code, inspect the application settings for proxy-related entries and check whether a manually configured proxy points to an old address. A stale value such as http://127.0.0.1:7890 is incorrect if the current mixed port has changed.
Also inspect environment variables in the shell that launches the editor:
echo "$HTTP_PROXY"
echo "$HTTPS_PROXY"
echo "$ALL_PROXY"
echo "$NO_PROXY"On Windows PowerShell, use:
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXYConflicting variables can produce confusing results. For example, the desktop application may use the operating system proxy while a terminal-launched editor inherits an outdated HTTPS_PROXY. A broad NO_PROXY entry can also bypass Clash for domains that should use the proxy. Remove obsolete values, restart the editor completely, and test again. Restarting matters because extensions commonly retain network clients and authentication state for the lifetime of the process.
Do not disable TLS verification globally to solve a Copilot timeout. A timeout is normally a routing or reachability problem, while certificate errors indicate interception, an incorrect system clock, a broken certificate chain, or an untrusted local inspection proxy. Turning off verification can hide the actual fault and weakens the security of all HTTPS traffic. If the log reports certificate errors, check the system date, installed security software, enterprise certificates, and whether the node or network is rewriting TLS traffic.
Choose between system proxy and TUN mode
System proxy mode is the simplest starting point. It works well for browsers and applications that honor the operating system’s HTTP or SOCKS settings. It is also easier to isolate because only applications that explicitly use the proxy are affected. Enable the system proxy in the Clash client, confirm the local address and port, restart the editor, and watch the connection log while requesting a suggestion.
TUN mode is appropriate when the editor, language server, terminal process, or authentication helper ignores the system proxy. TUN creates a virtual network interface and redirects traffic at the network layer, allowing applications without proxy controls to enter Clash routing. It also introduces more variables: administrator permissions, route installation, DNS interception, IPv6 behavior, and conflicts with other VPN or security software.
| Mode | Best initial use | Typical failure | What to inspect |
|---|---|---|---|
| System proxy | Browsers and proxy-aware editors | Extension bypasses the proxy | OS proxy, editor proxy, and environment variables |
| TUN enabled | Applications that ignore system proxy settings | Permission, route, or DNS conflict | Virtual interface, route table, DNS mode, and other VPNs |
| Manual application proxy | Testing one editor without changing all traffic | Wrong protocol or stale port | HTTP versus SOCKS5 support and local listener address |
When testing TUN, disable other VPN clients and temporarily turn off duplicated traffic interception. Confirm that the TUN interface is actually running, not merely enabled in the interface. On systems with separate IPv6 routing, test whether IPv6 is escaping through a path that the selected policy does not support. If TUN fixes suggestions but breaks local development services, add carefully reviewed bypass rules for private networks rather than disabling all routing protection.
A safe recovery sequence
- Stop the editor and keep the current Clash configuration backed up.
- Confirm that the core is running and record the actual mixed port.
- Choose one reliable node manually instead of relying on an unstable automatic group.
- Enable system proxy mode and test GitHub, then inspect the Clash log.
- Check the editor proxy settings and remove stale environment variables.
- If the editor still bypasses the proxy, enable TUN and grant the required system permission.
- Test DNS and IPv6 behavior without changing several resolver settings at once.
- Review the matched rule for each Copilot-related hostname and correct only the necessary routes.
- Restart the editor, sign in again if required, and test both authentication and suggestions.
If the same node fails on several networks while another node works immediately, replace or report the node rather than continuously modifying Clash. If every node fails but ordinary GitHub traffic works, inspect the current Copilot service status, the extension version, account entitlement, and editor logs. A successful Clash connection proves network reachability only; it does not prove that the extension is authenticated or that the account is permitted to use Copilot.