GitHub Copilot 一直超时？Clash 代理排查与修复

先判断：Copilot 超时到底卡在哪一层

GitHub Copilot出现「一直转圈」、代码补全迟迟不返回、Chat 面板空白或登录页反复跳转时，不要第一时间反复更换节点。使用 Clash 的设备通常同时涉及编辑器进程、系统代理、DNS 解析和规则组四个层面，任何一层没有接上，最终都可能被 Copilot 统一表现为 timeout、ETIMEDOUT、ECONNRESET 或登录失败。

Copilot 的请求也不是只访问一个地址。登录阶段通常会经过 GitHub 账户、设备授权或 OAuth 页面；编辑器运行时还要访问 Copilot 服务接口、策略接口、遥测端点以及静态资源。你在浏览器里能打开 github.com，并不代表 VS Code、JetBrains 或其他编辑器中的 Copilot 扩展已经通过 Clash 走上了同一条代理路径。尤其在 Windows 和 macOS 上，图形应用可能读取系统代理，而扩展宿主、远程开发进程或内置 Node 运行时却有自己的网络行为。

排查时建议先记录具体现象。若 GitHub 首页无法打开，优先检查系统代理和节点；若首页正常但 Copilot 登录失败，重点看授权域名、浏览器回调和扩展状态；若登录成功而补全超时，则重点查看 Copilot API 的连接日志、规则命中情况和长连接稳定性。若只有 Remote SSH 或 Dev Container 中的 Copilot 出问题，还要额外检查远端环境是否继承了代理变量。

检查系统代理、编辑器和 Clash 入站端口

打开 Clash 客户端后，先确认核心处于运行状态，并检查当前配置是否真的被激活。很多「Copilot 超时」其实发生在配置文件已经导入、但用户没有切换到该配置，或者 Clash 进程启动后监听端口被其他应用占用。常见的 HTTP、HTTPS 或 mixed-port 可能是 7890、7897 等，但不要照抄端口号，应以客户端设置页显示的实际值为准。

接着检查系统代理。Windows 可在「设置 → 网络和 Internet → 代理」确认手动代理是否指向 Clash 的本机地址；macOS 则在「系统设置 → 网络 → 当前连接 → 详细信息 → 代理」中查看 HTTP 与 HTTPS 代理。Clash Verge、Clash Verge Rev 或 Mihomo 客户端通常也提供「设置为系统代理」开关。开启后，可以用浏览器访问 GitHub，再在 Clash 的连接面板观察是否出现对应请求。

如果浏览器正常，而 VS Code 中的 Copilot 仍超时，不要直接认定是节点问题。编辑器可能运行在独立的扩展宿主进程中，也可能被企业策略、杀毒软件或旧代理环境变量影响。先完全退出编辑器，再重新启动 Clash 与编辑器；随后检查编辑器的代理设置是否留有过期的固定地址，例如曾经指向另一个端口的 http.proxy。旧代理设置与系统代理同时存在时，可能造成登录页面走一条路径、API 请求走另一条路径。

对终端启动的编辑器、脚本或远程开发工具，还应检查 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 是否指向当前 Clash 端口。环境变量并非越多越好：如果同时设置了 HTTP 代理、SOCKS 代理和旧的 PAC 地址，程序可能按照自己的优先级选择错误入口。建议暂时保留一种明确方式，验证 Copilot 恢复后再逐项加回其他环境配置。

用最小测试确认代理链路

测试不应一开始就打开大型项目。先关闭编辑器中的 Copilot 自动补全，打开一个空白文件，再重新启用扩展并观察 Clash 连接日志。若连接列表完全没有新请求，说明流量没有进入 Clash，应该回到系统代理、应用代理或 TUN 设置；若有请求但立即失败，则继续查看命中的规则、DNS 结果和节点错误信息。

• 核心运行正常，当前配置已激活，且本机监听端口没有冲突。
• 系统代理地址、编辑器代理地址和环境变量没有指向不同端口。
• Clash 日志能够看到 GitHub 或 Copilot 相关连接，而不是只有浏览器请求。
• 关闭 VPN、旧版代理客户端和重复的网络过滤器后，结果没有被其他软件改变。

检查规则组：GitHub 登录域与 Copilot 请求不能被误分流

在规则模式下，Clash 会根据域名、IP、进程或规则集选择策略组。Copilot 登录与运行时请求可能不是同一个主机，因此只把 github.com 加入代理并不一定足够。更可靠的做法是先在连接日志中查看真实请求，再决定是否将 GitHub 账户、授权页面和 Copilot 服务放入同一策略意图。不要凭网上几年前的域名清单盲目添加大量规则，因为服务端会调整接口，过宽的规则还可能误代理无关的 GitHub 流量。

如果日志显示 GitHub 登录页面走了代理，但某个 Copilot 请求命中了 DIRECT，这就是典型的半代理状态。登录凭证可能已经写入编辑器，但补全请求在 TLS 握手或服务端鉴权阶段失败。反过来，如果所有请求都进入代理，却只有某一条连接频繁重置，则应优先比较节点质量、出口地区和长连接稳定性，而不是继续扩大规则范围。

建议为开发者服务建立独立策略组，例如 CODING_AI，并将实际日志中确认的 GitHub 与 Copilot 相关域名交给该组。策略组可以先使用 select，方便手动更换节点；排障完成后，再考虑 url-test 或 fallback。不建议一开始使用负载均衡，因为多个节点同时承载登录、补全和流式请求，会增加会话状态不一致的可能性，使问题更难复现。

规则顺序同样重要。自定义代理规则必须位于宽泛的直连规则、地区规则或最终兜底规则之前，否则即使写入了正确的域名，也可能在更早的规则处结束匹配。修改 YAML 后先检查缩进、策略组名称和规则引用是否完全一致，再重载配置。若订阅更新会覆盖本地规则，应使用客户端支持的覆写、脚本或规则提供者机制保存修改，避免每次更新订阅后问题反复出现。

示例：用于排查的规则结构

rules:
  - DOMAIN-SUFFIX,github.com,CODING_AI
  - DOMAIN-SUFFIX,githubusercontent.com,CODING_AI
  - DOMAIN-SUFFIX,copilot.com,CODING_AI
  - MATCH,DIRECT

上面的片段只是结构示例，不能替代连接日志中的真实域名。某些编辑器版本、企业代理或 Copilot 功能可能使用不同的服务端地址；应以扩展日志和 Clash 连接面板为准。若你担心将整个 GitHub 生态都交给代理，可以先使用独立策略组验证，再按照实际请求逐条收窄范围。

节点质量、DNS 与 TUN 模式的进一步排查

当规则命中正确、请求也确实进入代理，但 Copilot 仍然超时时，就该把注意力转向节点质量。代码补全看似只是一个短请求，实际上编辑器可能维持持续连接、周期性刷新令牌，并在 Chat 或代码生成时接收较长的流式响应。一个测速延迟很低的节点，不一定适合长时间保持 TLS 连接；丢包、出口限流、连接空闲超时和高峰期拥塞都会表现为「偶尔能补全，稍微等待就卡住」。

选择节点时不要只看 Clash 界面上的延迟数字。可以连续观察同一节点在数分钟内的连接成功率、握手耗时和重置次数，再分别测试 GitHub 页面、登录流程和 Copilot 补全。若只有某个地区出口失败，可换同一策略组内的另一地区；若所有节点都失败，则更像是规则、账户状态、企业网络或客户端版本问题。

DNS 也会制造假象。Clash 的增强模式、Fake-IP、真实 IP 映射和系统 DNS 之间如果配置不一致，可能出现浏览器能打开、编辑器解析失败，或者域名解析到了不可用的地址。排查时暂时使用一套简单、稳定的 DNS 方案，清理系统和编辑器的 DNS 缓存，再重启 Clash 核心。不要在没有日志证据时同时更换 DNS、节点、规则和 TUN，否则无法知道是哪一步真正解决了问题。

TUN 模式适合处理不遵守系统代理的程序、扩展宿主和远程工具。开启前应确认 Clash 客户端拥有所需的系统权限，并关闭其他会创建虚拟网卡的 VPN 或网络加速器。Windows 上要留意路由表和防火墙，macOS 上则要关注网络扩展授权。TUN 开启后，如果普通浏览器反而无法联网，先回滚到系统代理模式，验证核心与节点，再重新处理虚拟网卡，而不是在多个网络层同时修改。

远程 SSH、WSL 和 Dev Container 是另一个独立边界。VS Code 窗口运行在本地，并不代表扩展或命令会在本地发请求；部分扩展会由远端服务器进程执行。此时需要在远端检查 DNS、代理环境变量和出站防火墙，也要确认远端是否能够访问本机的 Clash 监听地址。对于容器，127.0.0.1通常指向容器自身，而不是宿主机，直接填入这个地址很容易造成连接拒绝。

完成修改后，建议按照固定顺序复测：先重启 Clash 核心，再确认策略组当前节点，随后重启编辑器，最后重新登录 Copilot。每次只改变一个变量，并保留一份能正常工作的配置备份。相比反复点击「重新登录」或快速切换十几个节点，这种方法更容易从日志中找出真正的故障边界。

与只依赖浏览器代理的工具相比，部分编辑器内置代理设置较隐蔽，远程开发场景还可能需要额外配置；一些轻量客户端虽然操作简单，却缺少清晰的连接日志、规则命中信息和 TUN 控制。Clash V.CORE 在这类 Copilot 排障场景中更适合需要可观察性和精细分流的用户：你可以同时管理系统代理、规则组、DNS、节点健康状态与 TUN 接管范围，并用日志验证每一次请求。确认配置思路后，前往下载 Clash V.CORE，按本文的顺序逐层检查，通常比盲目更换节点更快恢复稳定的代码补全体验。