GitHub Copilot 连接超时？Clash 排查与修复方法

先判断超时发生在哪一层

GitHub Copilot 出现登录失败、连接超时、代码补全长时间不响应时，不要一开始就反复更换节点或重装编辑器。一次 Copilot 请求通常会经过编辑器扩展、编辑器的代理设置、操作系统网络、Clash 入站端口、规则匹配、代理节点以及 GitHub 相关服务多个环节。任何一层没有正确传递流量，界面都可能只显示“Timed out”“Failed to connect”或“Network error”。

排查前先记录四项信息：使用的编辑器和版本、Copilot 扩展版本、Clash 客户端与 mihomo 内核版本、完整错误信息。还要注明问题发生在登录阶段、聊天阶段还是代码补全阶段。登录失败通常与认证页面、浏览器回调或 GitHub 相关域名无法访问有关；聊天可用但补全失败，可能是扩展连接的服务端域名、长连接或编辑器代理配置存在差异。

检查 Clash 模式、节点与规则

Copilot 需要访问多个 GitHub、认证和服务接口，不能只根据浏览器能否打开 github.com 判断整体正常。Clash 处于“直连”模式时，GitHub 主站可能可以访问，但其他相关域名仍可能被当前网络阻断。处于“全局”模式时，所有流量都经过代理，虽然便于验证，却可能让本地服务、企业内网或编辑器扩展出现新的问题。长期使用通常建议采用规则模式，并为相关域名选择稳定的代理策略。

确认内核确实正在运行

打开 FlClash 或其他客户端的运行状态页，确认配置已经启动，并记录实际的混合端口。常见端口是 7890，但端口可能被修改，也可能使用独立的 HTTP 与 SOCKS5 端口。控制接口常见为 127.0.0.1:9090，它用于客户端管理内核，不是给浏览器或编辑器填写的代理端口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

如果编辑器代理设置填成了 127.0.0.1:9090，通常会导致连接失败或收到无法识别的响应。应用代理应填写 127.0.0.1:7890 以及正确的代理协议。使用 mixed-port 时，HTTP 与 HTTPS 请求通常都可以通过同一个混合端口转发；如果编辑器只支持 HTTP 代理，应确认客户端确实提供了 HTTP 入口，而不是只开启 SOCKS5。

用日志确认规则命中

测试 Copilot 时打开 Clash 的连接日志或实时请求列表。重新触发一次登录或代码补全，观察相关请求是否出现、命中了哪个规则、最终选择了哪个策略组。日志中如果完全没有请求，说明流量没有到达 Clash，优先检查系统代理、编辑器独立代理配置或 TUN 是否接管；如果请求出现但显示 REJECT、DIRECT 或错误节点，则应调整规则和策略组。

规则匹配按照从上到下的顺序执行。某条过宽的直连规则可能在 GitHub 规则之前提前生效，某条拒绝规则也可能拦截扩展使用的域名。不要只添加一个主域名就结束排查，因为认证页面、扩展服务、资源下载和 API 请求可能使用不同的主机名。域名应以编辑器扩展日志和 Clash 连接记录为依据，不要直接复制来源不明的整套规则。

选择稳定节点而不是只看测速

Copilot 的代码补全并不只是一次短网页请求，扩展可能需要维持较长的 HTTPS 连接或反复发送小型请求。因此节点选择不能只看一次延迟测试。一个延迟为 80 ms 但丢包很低的节点，实际体验可能优于延迟为 45 ms、数十秒后频繁重连的节点。

• 先使用一个明确可用的固定节点测试，不要一开始就使用频繁自动切换的 url-test。
• 测试期间避免多个设备同时大量下载，减少节点拥塞造成的误判。
• 如果只有某个地区节点失败，优先更换地区或线路，不要立即修改全部 DNS 和 TUN 参数。
• 节点切换后重新登录时，可能触发 GitHub 的安全验证；这不一定代表 Clash 配置错误。

校对编辑器代理与登录流程

浏览器可以正常访问 GitHub，并不代表 VS Code、JetBrains IDE 或其他编辑器一定使用同一条网络路径。部分编辑器继承操作系统代理，部分编辑器根据自身设置连接，还有一些扩展会读取编辑器的代理配置。若 Clash 日志中看不到 Copilot 请求，应先确认编辑器是否指向正确的本地代理端口。

VS Code 中的代理设置

在 VS Code 设置中搜索 proxy，检查 Http: Proxy、Http: Proxy Support 等选项。使用 Clash mixed-port 时，可以尝试填写：

http://127.0.0.1:7890

修改后完全退出并重新打开 VS Code，再观察 Clash 连接日志。不要把控制端口 9090 当作代理端口，也不要在没有必要时同时配置多个相互冲突的代理环境变量。若系统代理已经由 FlClash 设置，VS Code 的代理字段可以先保持自动或跟随系统；只有在自动模式没有请求进入 Clash 时，才使用明确的本地地址进行对照测试。

企业网络或本地开发环境可能依赖代理绕过列表。代理配置错误时，编辑器可以访问外网，却无法连接本机的扩展服务、远程开发主机或企业内网。排查时不要把所有地址都强制送入 Clash。先确认 Copilot 请求能够稳定进入代理，再逐项恢复本地开发所需的绕过项。

重新验证登录而不是反复改配置

登录失败时，先在编辑器中退出 GitHub 账号，再关闭编辑器并重启 Clash，确保代理状态稳定后重新登录。浏览器授权页面打开后，如果回调无法返回编辑器，可能是默认浏览器、编辑器进程权限或本机回调地址被代理规则影响。此时应查看编辑器的认证通知和扩展日志，不要仅凭网页显示“授权成功”就认为编辑器已经拿到令牌。

1. 确认 Clash 已启动，并固定使用一个可用节点。
2. 在浏览器中打开 GitHub 登录页，验证基础连接。
3. 在编辑器中退出当前 GitHub 账号，避免旧会话持续报错。
4. 重新执行登录，观察 Clash 日志是否出现认证相关连接。
5. 授权完成后等待扩展初始化，再测试一段普通代码补全。

如果浏览器可以访问 GitHub，编辑器也已经产生请求，但仍然提示超时，可以临时把 Clash 模式切换为全局进行一次对照。全局模式下恢复正常，说明规则或直连路径存在问题；全局模式下仍然失败，则继续检查节点、TLS、DNS、扩展版本和账号状态。测试结束后应切回规则模式，不建议长期使用全局模式代替正确的分流配置。

排查 TUN 与 DNS 造成的连接异常

TUN 模式会通过虚拟网卡接管不遵循系统代理的程序，适合命令行工具、部分桌面应用和无法配置代理的客户端。但它也会引入自动路由、DNS 劫持、IPv6、系统 VPN 和权限等变量。Copilot 已经能够通过系统代理正常工作时，不必为了“覆盖更多程序”立即启用 TUN。先用最简单的系统代理完成验证，往往更容易定位。

关闭 TUN 进行对照测试

1. 关闭 Clash 的 TUN 和增强模式，保留 mihomo 核心运行。
2. 开启系统代理，确认系统代理端口与当前配置的 mixed-port 一致。
3. 完全重启编辑器，再触发登录或补全。
4. 如果恢复正常，再单独开启 TUN 复测。

关闭 TUN 后恢复，通常说明问题与路由或 DNS 接管有关。开启 TUN 后继续超时，可先关闭“严格路由”、自动重定向或 IPv6 相关选项进行对照，但每次只改一个设置。不同操作系统和 mihomo 版本的 TUN 选项名称可能不同，应以当前客户端界面和内核文档为准，不要直接套用其他平台的配置。

确认 DNS 能够解析实际请求

DNS 污染或解析结果不稳定时，浏览器可能偶尔可以打开 GitHub，编辑器却在连接阶段超时。尤其是在 fake-ip、redir-host、系统 DNS 和代理端 DNS 混用时，域名解析路径可能与普通浏览器不同。查看 Clash 日志时，关注请求失败前是否出现 DNS 超时、连接到异常 IP、IPv6 连接失败后长时间回退等信息。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

上面的配置仅用于说明字段结构，不应直接覆盖现有订阅。实际 DNS 地址、监听方式和 fake-ip 过滤列表需要结合当前网络与客户端支持情况调整。修改前备份原配置，修改后重新启动核心，并确认规则集、代理组和本地服务仍然正常。若只在启用 IPv6 时失败，可以暂时禁用 IPv6 或让相关请求优先使用 IPv4，以判断是否为地址族兼容问题。

用逐步复测锁定根因

每次修改后都应完全重启编辑器或重新加载 Copilot 扩展，并记录是否能完成登录、是否出现补全、首次响应耗时以及 Clash 日志中的最终策略。这样可以避免多个变量同时变化，最后只能得到“好像恢复了”的模糊结论。