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。

这里要多说一句：排查 Copilot 前，先不要修改规则。启用 Clash Verge Rev、Mihomo Party 或你正在采用的 Clash 客户端，确认内核处于持续持续持续运行状态，配置文件已经成功加载，并且当前策略组不是空的。

如果订阅升级无法完成、配置解析无法完成，UI UI UI 界面有时仍然保留旧的代理开关，看起来像「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 连接。下面的端口只是示例，请替换成实际混合端口：

若命令行得以访问到到，而 IDE 仍然登录无法完成，困扰更或许出在编辑器没有继承系统代理、插件持续持续运行时采用了独立网络栈，或身份校验回调被本机安全软件拦截。

第二步：从连接日志确认 Copilot 请求命中了哪条规则 关键点梳理

这段示例不是永久域名清单，也不能保证覆盖各个未来版本的 Copilot 请求。添加规则后重新载入配置，在连接日志中确认真实域名是否命中 Copilot 策略组。

落到实处：「规则里已经写了 GitHub」并不等于 Copilot 流量一定走对。Clash 的规则按照从上到下的顺序匹配，某条更宽泛的 GEOIP、直连或代理规则或许在 GitHub 规则之前就结束匹配。

尤其是配置中存在 DOMAIN-SUFFIX,github.com,DIRECT、国内 IP 直连、进程分流或规则集覆盖时，Copilot 的身份校验请求或许被送到疏漏出口。

启用 Clash 的连接或日志页面，然后重新执行一次登录。不要只观察浏览器标签页，而要关注 VS Code 或 JetBrains 触发的连接。

别忽略了：普遍域名涵盖了 github.com、api.github.com、copilot-proxy.githubusercontent.com、githubusercontent.com，以及登录流程中出现的 OAuth 或设备授权相关主机。不同客户端版本或许采用不同的域名，最可信的依据是你本机连接日志里实际出现的主机名。

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

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

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

关键点是：若日志显示的是另一个主机名，不要凭猜测大范围添加域名，而应先确认该域名是否确实属于 GitHub 或 Copilot 的身份校验链路，再决定是否加入规则。

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

第三步：分别处理 VS Code 与 JetBrains 的代理继承 完备说明

VS Code 登录与 Copilot 扩展（速览）

如果 VS Code 得以启用 GitHub 页面但 Copilot 扩展仍然无法完成，启用「查看 → 输出」，在右侧下拉框中选定 GitHub Copilot 或相关扩展日志。

VS Code 多数现状下会参考系统代理，但具体行为会受到版本、扩展宿主进程和开启方式影响。先在 VS Code 设置中搜索 proxy，确认没有残留一个已经失效的人工代理地址。

如果你曾经填写过公司代理、旧端口或带身份校验的代理，VS Code 或许第一顺位采用这些设置，而不是当前 Clash 的系统代理。

这里要多说一句：可排查以下位置：设置中的 http.proxy、http.proxySupport、http.proxyStrictSSL，以及是否启用了不再采用的代理扩展。多数现状下应先让 VS Code 采用系统代理，而不是同时叠加多个代理层。

修改后彻底退出各个 VS Code 窗口，再重新开启，因为扩展宿主进程或许在窗口关闭后仍未立即结束。

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

JetBrains IDE 的独立代理设置（要点）

JetBrains 的 Git、终端、插件市场和 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 插件。

比如 Git 操作或许读取 Git 自行的 http.proxy，终端或许读取 HTTP_PROXY 环境变量，而 IDE 插件读取 JetBrains 的 HTTP Proxy。于是「能拉代码」不能径直证明「Copilot 登录一定能用」，应在每个实际无法完成的组件中查看日志。

第四步：TUN 与 DNS 排查，以及本机回调不要被误伤 要点速览

GitHub 的设备登录和编辑器授权有时会在本机开启回调服务，普遍地址是 127.0.0.1 或 localhost。本地回调多数现状下不最好通过代理转发，也不应被 TUN 规则误送到远端节点。

如果系统代理已经开启，但 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 域名都加入过滤列表，因为这或许让本应代理的解析回到本地网络。

排查系统防火墙、安全软件和端口占用，确认浏览器完成授权后能访问到到本机回调。如果回调端口被其他进程占用，关闭残留的 VS Code、JetBrains 或浏览器授权窗口后再试。

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

一套不绕路的完备排障顺序 关键信息

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

  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 帐号的困扰时，得以按下面顺序做一次干净测试。每完成一项就记录结果，不要同时修改五个开关，否则即使困扰消失，也无法知道真正有效的改动是什么。

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

普遍困扰：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，还要继续换节点吗？（要点）

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

如果连接已经完成 TLS 握手并平稳到达服务端，401 或 403 更或许与 Token、帐号授权、Copilot 订阅、组织策略或插件状态有关。

落到实处：得以先退出并重新登录、升级插件并排查帐号权限；只有当日志同时出现超时、连接重置或规则误命中时，才继续从 Clash 网络链路排查。

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