使用 Clash 时，GitHub Copilot 出现无法登录、代码补全失效、请求频繁超时，并不一定是 Copilot 账号或 VS Code 本身的问题。Copilot 的正常工作依赖多个域名、HTTPS 长连接以及稳定的代理出口，只要代理模式、规则匹配、节点质量或 DNS 解析其中一个环节异常，就可能表现为「登录页面打不开」「Copilot 初始化失败」或「一直显示 Connecting」。本文以 Clash 和 Mihomo 为例，按照代理模式、规则、节点、DNS 与客户端设置的顺序逐项排查，覆盖 VS Code 与 JetBrains IDE 的常见场景。

先判断问题发生在哪个环节

排查之前不要急着反复更换订阅或重装编辑器。GitHub Copilot 的请求通常会涉及 GitHub 登录、Copilot API、遥测和编辑器扩展服务，不同请求未必使用同一个域名。浏览器可以打开 github.com，并不代表 Copilot 的所有接口都能正常访问；同样，Clash 面板显示节点延迟正常，也不代表该节点能够稳定建立 Copilot 所需的 HTTPS 连接。

可以先根据现象进行初步分类：

表现优先检查项目常见原因
登录按钮无响应或网页打不开系统代理、规则与 DNS请求直连、域名解析错误、代理端口未生效
能登录但一直显示 Connecting节点质量、策略组、TLS 连接节点丢包、出口不稳定、规则走到错误策略组
偶尔能补全，随后频繁超时节点稳定性与连接日志节点拥塞、连接被重置、自动切换造成会话中断
VS Code 可用，JetBrains 不可用IDE 代理设置与环境变量两个客户端使用了不同的代理端口或代理模式
所有 GitHub 功能都失败Clash 核心状态与订阅核心未运行、配置加载失败、订阅节点全部失效

第一步建议打开 Clash 的连接面板，然后在 IDE 中重新触发一次登录或代码补全。观察是否出现目标域名、使用的策略组以及最终命中的规则。如果完全没有连接记录，问题更可能发生在 IDE 没有使用系统代理、Clash 没有接管该应用，或扩展在启动阶段就已经报错；如果能看到连接但状态为 timeout、reset 或 failed，则应继续检查节点和 DNS。

排查原则：每次只修改一个变量。先固定一个确认可用的节点，再测试规则；先确认浏览器与命令行能访问，再调整 IDE 设置。一次同时更换节点、模式和 DNS，会让故障原因变得无法判断。

检查代理模式与 GitHub 规则

Clash 常见的运行模式包括规则模式、全局代理模式和直连模式。规则模式适合日常使用，但前提是规则集覆盖了 Copilot 相关域名；全局代理模式会把所有连接交给当前代理组，适合短时间验证问题是否由规则导致。直连模式则会绕过代理，通常不适合直接访问受网络环境影响的 GitHub 服务。

可以先在 Clash 客户端中临时切换到全局代理，然后重新启动 VS Code 或 JetBrains，再测试登录和补全。如果全局模式下恢复正常，基本可以确定是规则没有覆盖完整，或者 GitHub 相关请求被错误地分配到了直连组。验证完成后应切回规则模式，并补充明确的域名规则，而不是长期使用全局代理。

GitHub Copilot 的域名可能随客户端版本、账号区域和服务端策略变化，不能只添加一个 github.com 就认为配置完整。建议在连接日志中记录实际出现的域名，再根据域名添加规则。常见的基础规则可以这样写：

GitHub 与 Copilot 基础规则示例
rules:
  - DOMAIN-SUFFIX,github.com,GitHub
  - DOMAIN-SUFFIX,githubusercontent.com,GitHub
  - DOMAIN-SUFFIX,githubassets.com,GitHub
  - DOMAIN-SUFFIX,githubcopilot.com,GitHub
  - DOMAIN-SUFFIX,copilot-proxy.githubusercontent.com,GitHub
  - MATCH,DIRECT

proxy-groups:
  - name: GitHub
    type: select
    proxies:
      - 自动选择
      - 手动节点
      - DIRECT

上面的策略组名称只是示例，必须替换成配置文件中真实存在的组名。规则顺序也非常重要：Clash 按从上到下的顺序匹配，若前面已经存在宽泛的 DOMAIN-KEYWORD,github,DIRECT，后面的代理规则就不会生效。修改配置后，要在客户端执行「重新加载配置」或「重载」操作；仅保存文件而没有让核心重新读取，旧规则仍可能继续工作。

从连接面板确认实际命中规则

不要只凭感觉判断规则是否生效。在 Clash Verge、Clash Verge Rev 或 Mihomo Dashboard 的「连接」页面中，触发一次 Copilot 请求后查看目标域名、规则类型和策略组。理想状态是相关请求命中 DOMAIN-SUFFIX 或其他明确的域名规则，并进入你指定的 GitHub 策略组。如果显示 FINAL、MATCH 或 DIRECT，说明它可能绕过了预期代理；如果显示代理组但组内当前节点为不可用，也会造成登录或补全失败。

动手操作：逐项修复 Copilot 连接

下面是一套适用于大多数 Clash 客户端的实际操作流程。不同版本的按钮名称可能略有区别，但判断逻辑基本相同。操作前建议关闭正在编辑的文件，避免扩展在切换网络过程中重复发起大量请求。

  1. 确认核心正在运行。打开 Clash 客户端，确认状态为运行中，并记下 HTTP 或 mixed port，例如 7890。如果客户端只有订阅页面而没有运行状态，可能只是导入了配置，并没有启动代理核心。
  2. 选择一个稳定节点。不要先使用自动选择组。手动选择一个延迟较低、连续测速结果稳定的节点，观察连接是否会频繁断开。延迟低不等于可用，至少应连续测试几次 HTTPS 请求。
  3. 临时切换为全局模式。重启 IDE 后测试 Copilot 登录。如果此时正常，记录连接面板中出现的实际域名，随后切回规则模式并补充规则。
  4. 确认系统代理开关。桌面客户端中打开「设置系统代理」或等效选项。若使用 TUN 模式，则确认 TUN 已启动且系统没有被其他 VPN、加速器或安全软件接管。
  5. 检查 IDE 自己的代理设置。VS Code 通常继承系统代理，但某些环境变量、远程开发窗口或扩展设置可能改变行为；JetBrains 则可以在 Settings 的 HTTP Proxy 中选择自动检测或手动填写 Clash 的本地端口。
  6. 重新进行登录授权。在 Copilot 扩展账户菜单中退出当前 GitHub 账号，再通过「Sign in to GitHub」重新授权。浏览器完成授权后，确认回到正确的 IDE 窗口，而不是另一个已经关闭的项目窗口。
  7. 查看输出日志。VS Code 可在「输出」面板选择 GitHub Copilot 或 GitHub Copilot Chat；JetBrains 可查看 IDE 日志和插件日志。若日志提示 proxy、certificate、socket 或 timeout，分别对应代理、证书、连接和超时方向。
  8. 逐项恢复设置。规则模式、自动节点、TUN 和自定义 DNS 不要一次全部打开。每恢复一项就测试一次，这样可以快速确定是哪一个设置导致连接失败。
不要随意开启跳过证书验证：如果日志出现 TLS 或证书错误，优先检查系统时间、根证书、杀毒软件的 HTTPS 扫描以及节点服务端证书。将 skip-cert-verify 设为 true 只能隐藏问题，还会降低连接安全性，不建议作为长期修复方案。

如果使用远程开发容器、WSL、SSH Remote 或 JetBrains Gateway，还要注意代理运行在宿主机，而 IDE 进程可能运行在另一台机器或虚拟环境中。此时 127.0.0.1:7890 指向的是远程环境自身，而不是本地电脑。应确认远程环境能够访问宿主机的代理地址，并根据网络拓扑填写正确的局域网 IP；同时不要把未保护的代理端口直接暴露到公网。

节点与 DNS 导致的超时问题

当规则已经正确命中，但 Copilot 仍然频繁超时，下一步应把注意力放在节点质量上。Copilot 代码补全对延迟敏感，聊天功能和登录授权还需要持续、完整的 HTTPS 连接。某些节点可以打开网页，却会在长连接、较大响应或高并发请求时被重置。建议分别测试两个或三个节点，不要只依据 Clash 面板中的单次延迟数字作决定。

可以重点观察以下指标：

  • 丢包与抖动：延迟从 80 毫秒突然跳到 1000 毫秒，通常比稳定的 180 毫秒更容易导致补全超时。
  • 连接重置：连接建立后立即断开，可能是节点出口限制、TLS 处理异常或线路对长连接不友好。
  • 节点出口地区：某些服务会根据出口 IP、账号区域或风险评分改变响应，换到其他地区节点可以帮助确认是否为出口问题。
  • 自动切换：url-test 或 fallback 在测试期间切换节点，会使已有连接中断。排查时应固定节点，确认稳定后再恢复自动策略。

DNS 异常通常表现为某个域名打不开、连接面板显示错误 IP，或者同一节点在不同网络下结果完全不同。Mihomo 用户可以优先尝试 fake-ip 模式，让规则基于域名匹配，并使用可靠的远程 DNS 处理境外域名。配置时不要把本地运营商 DNS、浏览器安全 DNS 和 Clash DNS 多层叠加到无法判断的状态。

Mihomo DNS 排查示例
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

profile:
  store-selected: true
  store-fake-ip: true

修改 DNS 后需要清理缓存并重新建立连接。可以重启 Clash 核心、刷新系统 DNS 缓存，再完全退出并重新打开 IDE。若开启 TUN 后出现所有域名都无法解析，先关闭 TUN 验证普通系统代理是否正常；如果关闭后恢复，说明问题集中在 TUN 的路由、网卡权限、虚拟网卡冲突或 DNS 劫持，而不是 Copilot 账户本身。

VS Code 与 JetBrains 的客户端设置

VS Code 的 Copilot 扩展一般会使用系统网络环境，但代理相关的环境变量仍可能产生影响。检查是否设置了过期的 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，尤其要留意它们是否指向另一个已经停止运行的端口。使用 Remote-SSH 或 Dev Container 时，应在实际运行扩展的远程环境中检查变量，而不是只查看本地终端。

在 VS Code 中，可以打开命令面板执行 Copilot 相关的重新登录命令，并在「输出」面板确认扩展是否成功初始化。若登录网页可以打开但授权回调失败，检查系统默认浏览器、回调地址是否被安全软件拦截，以及是否同时打开了多个 VS Code 窗口。必要时退出所有 VS Code 进程后重新启动，再进行一次干净授权。

JetBrains IDE 的网络请求可能遵循 IDE 自己的 HTTP Proxy 配置。进入 Settings → Appearance & Behavior → System Settings → HTTP Proxy，先尝试「Auto-detect proxy settings」；如果自动检测不稳定，可以手动填写 Clash 的 HTTP 代理地址和端口。不要把 SOCKS5 端口误填到 HTTP 代理选项中，除非该客户端明确支持 SOCKS5。设置完成后使用 IDE 提供的连接测试功能，再重启 Copilot 插件。

如果 VS Code 和 JetBrains 只有一个能用，优先比较三项：两者实际使用的代理端口、是否运行在本地或远程环境、以及 Clash 连接日志中是否出现不同的域名。通常不需要修改 Copilot 的账号设置，先让两个客户端经过同一个确认可用的 Clash 代理，再处理插件版本或缓存问题。

最后，建议保留一份已验证的最小配置：固定一个节点、规则模式只代理 GitHub 相关域名、关闭不必要的 TUN 增强选项，并使用稳定的 DNS。确认 Copilot 可以连续完成登录、补全和聊天请求后，再逐步恢复自动选优、规则提供者和其他网络工具。这样即使问题再次出现，也能通过连接日志迅速定位，而不必反复重装编辑器或删除账号数据。

立即开始

用 Clash 掌控你的流量

支持 Windows、macOS、Linux、Android 与 iOS，灵活规则，开箱即用。

免费下载 查看设置指南 →