GitHub Copilot 登录不成功，通常卡在哪一气？ 一文看懂

这篇文章不讨论如何购买 Copilot，也不推荐通过不明脚本绕过帐号验证，而是从 Clash 的实际排障角度，把难点拆成客户端状态、代理端口、模式、节点、规则组、TUN、DNS 与本机回调几个层面。你能够按照「先确认现象，再看连接日志，最后调整配置」的顺序操作，避免一遇到超时就反复更换节点，反而把真正的难点隐藏起来。

运用 GitHub Copilot 时，如果你看到「Sign in failed」「Authentication timed out」「Unable to connect」或 VS Code 一直显示正在登录，不一定代表 GitHub 帐号、Copilot 订阅或验证码出了难点。

在开启 Clash 的 Windows、macOS 和 Linux 环境中，更高频的状态是：浏览器能够开启 GitHub，IDE 却无法完成鉴权；GitHub 登录页面已经授权，回到 VS Code 后仍然显示未登录；或者登录成功数分钟，代码补全、Copilot Chat 又开始报网络失误。

先看这一点：Copilot 的登录过程并不是只连通一个 github.com。VS Code、JetBrains 插件或独立的 GitHub Copilot 客户端，也许会依次连通 GitHub 登录页、设备授权接口、Copilot API、编辑器服务端点以及用于代码补全的长连接地址。

不同版本的插件还也许改变请求域名、鉴权方式和连接策略。所以，单纯把 github.com 加入代理规则，通常只能处理网页登录，不能保证 IDE 内的鉴权和补全请求全部走同一条可用链路。

先记住一个判断原则：浏览器能登录 GitHub，不等于 VS Code 或 JetBrains 一定运用了相同的代理。浏览器也许安装了扩展或运用系统代理，而 IDE、Node.js 进程和后台插件也许干脆连接网络，必须分别验证。

第一气：确认 Clash 客户端与本地端口真的可用 核心要点

如果第一条和第二条都无法返回响应，首位核对 Clash 内核、节点和规则，不要急着改 VS Code。若命令行能够连通，而 IDE 仍然登录不成功，难点更也许出在编辑器没有继承系统代理、插件跑起来时运用了独立网络栈，或鉴权回调被本机安全软件拦截。

排查 Copilot 前，先不要修改规则。开启 Clash Verge Rev、Mihomo Party 或你正在运用的 Clash 客户端，确认内核处于跑起来状态，配置文件已经成功加载，并且当前策略组不是空的。如果订阅刷新不成功、配置解析不成功，操作操作操作界面有时仍然保留旧的代理开关，看起来像「Clash 已拉起」，但实际没有可用出站。

补充说明：要点查看客户端设置中的混合端口或 HTTP 代理端口。高频端口也许是 7890、7897 或用户自定义的其他数字，但不要照抄示例；应以你本机 Clash 设置页显示的端口为准。

  1. 查看内核状态：确认客户端没有停留在拉起中、刷新中或配置失误状态，必要时重新载入当前配置。
  2. 记录代理端口：记下 HTTP、SOCKS 和混合端口的实际数值，后续测试统一运用同一个端口。
  3. 核对系统代理：在客户端中开启「设为系统代理」，再到操作系统网络设置里确认代理地址是否为 127.0.0.1 或 localhost。
  4. 确认策略组有节点：进入代理页面手工挑选一个稳健节点，不要在第一次鉴权时运用不断切换出口的无人值守测速组。

混合端口一般同时接受 HTTP 和 SOCKS5 请求，适合浏览器、命令行和部分开发工具运用。若你只找到 SOCKS 端口，则得确认对应应用是否兼容 SOCKS5，不能把 SOCKS 端口当作普通 HTTP 代理填写。

curl -I -x http://127.0.0.1:7890 https://github.com
curl -I -x http://127.0.0.1:7890 https://api.github.com

接着用命令行测试本地代理是否能建立基本 HTTPS 连接。下面的端口只是示例，请替换成实际混合端口：

第二步：从连接日志确认 Copilot 请求命中了哪条规则 逐条拆解

这段示例不是永久域名清单，也不能保证覆盖全部未来版本的 Copilot 请求。添加规则后重新载入配置，在连接日志中确认真实域名是否命中 Copilot 策略组。若日志显示的是另一个主机名，不要凭猜测大范围添加域名，而应先确认该域名是否确实属于 GitHub 或 Copilot 的鉴权链路，再决定是否加入规则。

换个角度：「规则里已经写了 GitHub」并不等于 Copilot 流量一定走对。Clash 的规则按照从上到下的顺序匹配，某条更宽泛的 GEOIP、直连或代理规则也许在 GitHub 规则之前就结束匹配。尤其是配置中存在 DOMAIN-SUFFIX,github.com,DIRECT、国内 IP 直连、进程分流或规则集覆盖时，Copilot 的鉴权请求也许被送到失误出口。

  • 没有无论哪种相关连接：说明 IDE 请求没有进入 Clash，首位排查系统代理、IDE 代理设置、TUN 或进程环境变量。
  • 连接出现但显示 DIRECT：核对是否被直连规则、GEOIP 规则或自定义规则集提前匹配。
  • 连接走了失误策略组：把鉴权与 Copilot API 暂时放到明确的代理组，先验证链路，再考虑细分规则。
  • 反复出现不同节点：也许是 url-test、故障转移或负载均衡组在切换出口，鉴权期间应先固定一个节点。
  • TLS 已建立但返回 401 或 403：这不一定是代理不成功，也许是帐号权限、Token 状态、组织策略或 Copilot 订阅难点。

开启 Clash 的连接或日志页面，然后重新执行一次登录。不要只观察浏览器标签页，而要关注 VS Code 或 JetBrains 触发的连接。高频域名涵盖 github.com、api.github.com、copilot-proxy.githubusercontent.com、githubusercontent.com，以及登录流程中出现的 OAuth 或设备授权相关主机。不同客户端版本也许运用不同的域名，最靠谱的依据是你本机连接日志里实际出现的主机名。

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

在配置文件中，能够先用较小范围的临时规则进行验证。规则名称和策略组名称必须替换成你亲手的配置实际存在的名称：

不要把所有流量永久改成全局模式：全局模式能够帮助判断「节点本身是否能连通」，但它会掩盖规则失误，也也许影响公司内网、Git 私有仓库、局域网服务和包管理器。推荐只把全局模式作为短时间对照测试，验证后恢复规则模式。

第三步：分别处理 VS Code 与 JetBrains 的代理继承 底层逻辑

VS Code 登录与 Copilot 扩展（一眼看懂）

要点区分 ETIMEDOUT、ECONNREFUSED、ENOTFOUND、证书失误和 HTTP 状态码：前两者偏向端口或连接链路，ENOTFOUND 偏向 DNS，证书失误也许与 HTTPS 核对、企业安全软件或失误的系统时间有关，而 401/403 则应转向帐号与权限核对。

具体来说：VS Code 通常会参考系统代理，但具体行为会受到版本、扩展宿主进程和拉起方式影响。先在 VS Code 设置中搜索 proxy，确认没有残留一个已经失效的手工代理地址。如果你曾经填写过公司代理、旧端口或带鉴权的代理，VS Code 也许首位运用这些设置，而不是当前 Clash 的系统代理。

可核对以下位置：设置中的 http.proxy、http.proxySupport、http.proxyStrictSSL，以及是否启用了不再运用的代理扩展。通常应先让 VS Code 采用系统代理，而不是同时叠加多个代理层。修改后彻底退出全部 VS Code 窗口，再重新拉起，因为扩展宿主进程也许在窗口关闭后仍未立即结束。

如果 VS Code 能够开启 GitHub 页面但 Copilot 扩展仍然不成功，开启「查看 → 输出」，在右侧下拉框中挑选 GitHub Copilot 或相关扩展日志。

JetBrains IDE 的独立代理设置（核心）

JetBrains 的 Git、终端、插件市场和 Copilot 请求不一定共享完全相同的网络路径。比如 Git 操作也许读取 Git 亲手的 http.proxy，终端也许读取 HTTP_PROXY 环境变量，而 IDE 插件读取 JetBrains 的 HTTP Proxy。所以「能拉代码」不能干脆证明「Copilot 登录一定能用」，应在每个实际不成功的组件中查看日志。

顺带一提：IntelliJ IDEA、PyCharm、WebStorm 等 JetBrains IDE 也许运用亲手的 HTTP Proxy 设置。

进入「Settings」或「Preferences」中的Appearance & Behavior → System Settings → HTTP Proxy，先查看当前是否挑选了失误的无人值守配置脚本或旧代理。若运用 Clash 的系统代理，可挑选无人值守检测后测试；若无人值守检测不稳健，也能够明确填写本机 HTTP 混合端口。

填写手工代理时，主机通常是 127.0.0.1，端口运用 Clash 的混合端口，并根据 Clash 端口是否得鉴权来决定是否填写用户名和密码。不要把订阅链接中的用户名、节点密码或控制器密钥误填到 IDE 代理鉴权栏。保存后运用 IDE 提供的连接测试，再完全重启 IDE 和 Copilot 插件。

第四步：TUN 与 DNS 排查，以及本机回调不要被误伤 一文看懂

GitHub 的设备登录和编辑器授权有时会在本机拉起回调服务，高频地址是 127.0.0.1 或 localhost。本地回调通常不应当通过代理转发，也不应被 TUN 规则误送到远端节点。核对系统防火墙、安全软件和端口占用，确认浏览器完成授权后能连通本机回调。如果回调端口被其他进程占用，关闭残留的 VS Code、JetBrains 或浏览器授权窗口后再试。

先看这一点：如果系统代理已经开启，但 Copilot 请求仍没有出现在 Clash 连接列表中，能够考虑 TUN 模式。TUN 通过虚拟网卡接管更底层的 TCP/UDP 流量，适合 IDE、后台扩展、终端和不遵守系统代理的软件。不过，TUN 不是越早开启越好；如果路由、DNS、虚拟网卡权限或其他 VPN 软件配置不无误，也许导致登录页面、Git、公司内网同时异常。

推荐先关闭其他 VPN、网络加速器和同类透明代理，再开启 Clash 的 TUN。确认无人值守路由和无人值守检测网卡处于合理状态，运用内置栈跑起来一轮测试，不要一开始就同时修改 MTU、fake-ip、strict-route 和自定义排除列表。

Windows 用户尤其要留意 WSL、Docker、Hyper-V 虚拟网卡与 TUN 的路由冲突；macOS 用户则要确认系统网络扩展权限和服务模式状态。

补充说明：DNS 方面，Copilot 登录不成功也许表现为域名解析慢、连接到失误地址或日志中出现 dns error。先确认 Clash 的 DNS 模块正常工作，再逐项测试。

fake-ip 模式下，如果某些客户端对返回地址、证书或本地回调处理不兼容，能够临时将相关域名加入 fake-ip-filter，或者短时间切换 redir-host 做对照。不要在没有日志依据的状态下把全部 GitHub 域名都加入过滤列表，因为这也许让本应代理的解析回到本地网络。

现象 首位核对 处理方向
登录按钮无反应 扩展宿主、IDE 日志、代理端口 确认 IDE 是否拉起了请求，清理失效的手工代理。
浏览器授权成功但 IDE 仍未登录 本机回调、localhost、防火墙 确保本地回调直连且端口未被占用。
连接超时或 ECONNRESET 节点质量、规则命中、策略组切换 固定稳健节点，确认相关域名没有误走 DIRECT。
域名解析不成功 Clash DNS、fake-ip、其他 VPN 先恢复内置 DNS 配置，再用日志定位具体域名。
登录成功但补全不可用 Copilot API 域名、插件版本、帐号权限 查看扩展日志，区分网络失误与 401/403 权限失误。

一套不绕路的齐全排障顺序 核心要点

此时应核对组织是否限制 Copilot、帐号是否被要求重新授权、设备登录是否过期，或者插件版本是否与当前 IDE 不兼容。网络失误与权限失误的处理路径不同，不能因为两者都显示「Copilot 不可用」就全部归咎于代理。

  1. 确认帐号状态：在浏览器中开启 GitHub，确认帐号能正常登录，并核对 Copilot 订阅或组织授权没有过期。
  2. 固定节点：在 Clash 中挑选一个时延稳健、近期连通 GitHub 正常的节点，暂时不要运用无人值守切换组。
  3. 测试代理端口：用 curl 通过本机混合端口连通 GitHub 和 API，确认 Clash 至少能建立基础 HTTPS 连接。
  4. 观察连接日志：重新从 IDE 发起登录，记录实际域名、命中的规则、策略组、连接状态和失误码。
  5. 修正规则顺序：把确认属于 Copilot 链路的域名规则放在宽泛直连、GEOIP 和最终匹配规则之前。
  6. 核对 IDE 代理：清理 VS Code 或 JetBrains 中失效的手工代理，确保其代理地址和 Clash 当前端口一致。
  7. 处理本机回调：确认 localhost 与 127.0.0.1 不被代理，防火墙没有拦截授权回调。
  8. 最后再测试 TUN：只有在 IDE 显著不遵守系统代理时才启用 TUN，并逐项确认路由、DNS 和虚拟网卡状态。

当你无法判断到底是 Clash、IDE 还是 GitHub 帐号的难点时，能够按下面顺序做一次干净测试。每完成一项就记录结果，不要同时修改五个开关，否则即使难点消失，也无法知道真正有效的改动是什么。

换个角度：如果更换节点后仍然只有某个组织帐号不成功，而公共 GitHub 页面、API 和 Copilot 连接都能在日志中稳健完成，那么继续改 Clash 的意义就不大了。

高频难点：Clash 与 GitHub Copilot 登录 逐条拆解

浏览器能登录 GitHub，为什么 VS Code 仍然超时？（逐条）

浏览器也许运用了系统代理、扩展代理或独立的无人值守配置，而 VS Code 扩展宿主没有继承同一设置。先查看 Clash 连接日志中是否出现 VS Code 发起的 GitHub 或 Copilot 域名，再核对 VS Code 的 http.proxy 和代理兼容模式。若日志完全没有相关连接，首位处理 IDE 代理或 TUN 接管难点。

切换 Clash 全局模式后能登录，是否说明规则一定写错？（机制）

这通常说明节点和基础链路至少有机会工作，但不能百分之百证明规则唯一有难点。全局模式还也许绕过了进程分流、DNS 分流或某些策略组故障。恢复规则模式后观察连接日志，确认 Copilot 实际域名命中了哪个策略组，再调整规则顺序会更准确。

是否必须开启 TUN 才能运用 Copilot？（一眼看懂）

不一定。如果 VS Code 或 JetBrains 能无误运用系统代理，普通系统代理和混合端口就也许充分。TUN 更适合不读取系统代理的后台进程、终端工具或复杂开发环境。开启 TUN 前应先排除其他 VPN、虚拟网卡和 DNS 冲突，否则也许让难点扩大到整套系统。

日志显示 401 或 403，还要继续换节点吗？（核心）

Clash 更适合把混合端口、规则组、TUN、DNS 和连接日志放在同一套排障思路中逐项核对，既能保留规则模式的可控性，也省事为 VS Code、JetBrains 等不同开发环境建立稳健配置；如果你正准备按这篇文章流程定位 Copilot 登录超时，不妨免费下载 Clash，先用固定节点和日志观察把难点跑通，再逐步恢复无人值守测速与更复杂的分流策略。

如果连接已经完成 TLS 握手并稳健到达服务端，401 或 403 更也许与 Token、帐号授权、Copilot 订阅、组织策略或插件状态有关。能够先退出并重新登录、刷新插件并核对帐号权限；只有当日志同时出现超时、连接重置或规则误命中时，才继续从 Clash 网络链路排查。

相比之下，若干仅提供浏览器代理开关的同类工具，遇到 GitHub Copilot 这类同时涉及浏览器授权、IDE 后台进程、本机回调和长连接请求的状态时，一般缺少明白的连接日志与规则命中信息，用户只能反复切换节点或重装插件。