GitHub Copilot 登录失败，通常卡在哪一步？
使用 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 内的认证和补全请求全部走同一条可用链路。
本文不讨论如何购买 Copilot，也不建议通过不明脚本绕过帐号验证，而是从 Clash 的实际排障角度，把问题拆成客户端状态、代理端口、模式、节点、规则组、TUN、DNS 与本机回调几个层面。你可以按照「先确认现象，再看连接日志，最后调整配置」的顺序操作，避免一遇到超时就反复更换节点，反而把真正的问题隐藏起来。
先记住一个判断原则：浏览器能登录 GitHub，不等于 VS Code 或 JetBrains 一定使用了相同的代理。浏览器可能安装了扩展或使用系统代理，而 IDE、Node.js 进程和后台插件可能直接连接网络，必须分别验证。
第一步：确认 Clash 客户端与本地端口真的可用
排查 Copilot 前，先不要修改规则。打开 Clash Verge Rev、Mihomo Party 或你正在使用的 Clash 客户端，确认内核处于运行状态，配置文件已经成功加载，并且当前策略组不是空的。如果订阅更新失败、配置解析失败，界面有时仍然保留旧的代理开关，看起来像「Clash 已启动」，但实际没有可用出站。
重点查看客户端设置中的混合端口或 HTTP 代理端口。常见端口可能是 7890、7897 或用户自定义的其他数字，但不要照抄示例；应以你本机 Clash 设置页显示的端口为准。混合端口通常同时接受 HTTP 和 SOCKS5 请求，适合浏览器、命令行和部分开发工具使用。若你只找到 SOCKS 端口，则需要确认对应应用是否支持 SOCKS5，不能把 SOCKS 端口当作普通 HTTP 代理填写。
- 查看内核状态：确认客户端没有停留在启动中、更新中或配置错误状态，必要时重新载入当前配置。
- 记录代理端口：记下 HTTP、SOCKS 和混合端口的实际数值，后续测试统一使用同一个端口。
- 检查系统代理：在客户端中开启「设为系统代理」，再到操作系统网络设置里确认代理地址是否为
127.0.0.1或localhost。 - 确认策略组有节点：进入代理页面手动选择一个稳定节点，不要在第一次认证时使用不断切换出口的自动测速组。
接着用命令行测试本地代理是否能建立基本 HTTPS 连接。下面的端口只是示例，请替换成实际混合端口：
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如果第一条和第二条都无法返回响应，优先检查 Clash 内核、节点和规则，不要急着改 VS Code。若命令行可以访问，而 IDE 仍然登录失败，问题更可能出在编辑器没有继承系统代理、插件运行时使用了独立网络栈，或认证回调被本机安全软件拦截。
第二步：从连接日志确认 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这段示例不是永久域名清单，也不能保证覆盖所有未来版本的 Copilot 请求。添加规则后重新载入配置，在连接日志中确认真实域名是否命中 Copilot 策略组。若日志显示的是另一个主机名，不要凭猜测大范围添加域名，而应先确认该域名是否确实属于 GitHub 或 Copilot 的认证链路，再决定是否加入规则。
不要把所有流量永久改成全局模式：全局模式可以帮助判断「节点本身是否能连通」，但它会掩盖规则错误，也可能影响公司内网、Git 私有仓库、局域网服务和包管理器。建议只把全局模式作为短时间对照测试，验证后恢复规则模式。
第三步：分别处理 VS Code 与 JetBrains 的代理继承
VS Code 登录与 Copilot 扩展
VS Code 通常会参考系统代理，但具体行为会受到版本、扩展宿主进程和启动方式影响。先在 VS Code 设置中搜索 proxy，确认没有残留一个已经失效的手动代理地址。如果你曾经填写过公司代理、旧端口或带认证的代理，VS Code 可能优先使用这些设置，而不是当前 Clash 的系统代理。
可检查以下位置：设置中的 http.proxy、http.proxySupport、http.proxyStrictSSL，以及是否启用了不再使用的代理扩展。通常应先让 VS Code 采用系统代理，而不是同时叠加多个代理层。修改后彻底退出所有 VS Code 窗口，再重新启动，因为扩展宿主进程可能在窗口关闭后仍未立即结束。
如果 VS Code 可以打开 GitHub 页面但 Copilot 扩展仍然失败，打开「查看 → 输出」，在右侧下拉框中选择 GitHub Copilot 或相关扩展日志。重点区分 ETIMEDOUT、ECONNREFUSED、ENOTFOUND、证书错误和 HTTP 状态码：前两者偏向端口或连接链路，ENOTFOUND 偏向 DNS，证书错误可能与 HTTPS 检查、企业安全软件或错误的系统时间有关，而 401/403 则应转向帐号与权限检查。
JetBrains IDE 的独立代理设置
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 插件。
JetBrains 的 Git、终端、插件市场和 Copilot 请求不一定共享完全相同的网络路径。比如 Git 操作可能读取 Git 自己的 http.proxy，终端可能读取 HTTP_PROXY 环境变量，而 IDE 插件读取 JetBrains 的 HTTP Proxy。因此「能拉代码」不能直接证明「Copilot 登录一定能用」，应在每个实际失败的组件中查看日志。
第四步：TUN 与 DNS 排查，以及本机回调不要被误伤
如果系统代理已经开启，但 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 域名都加入过滤列表，因为这可能让本应代理的解析回到本地网络。
GitHub 的设备登录和编辑器授权有时会在本机启动回调服务，常见地址是 127.0.0.1 或 localhost。本地回调通常不应该通过代理转发，也不应被 TUN 规则误送到远端节点。检查系统防火墙、安全软件和端口占用，确认浏览器完成授权后能访问本机回调。如果回调端口被其他进程占用，关闭残留的 VS Code、JetBrains 或浏览器授权窗口后再试。
| 现象 | 优先检查 | 处理方向 |
|---|---|---|
| 登录按钮无反应 | 扩展宿主、IDE 日志、代理端口 | 确认 IDE 是否启动了请求，清理失效的手动代理。 |
| 浏览器授权成功但 IDE 仍未登录 | 本机回调、localhost、防火墙 | 确保本地回调直连且端口未被占用。 |
| 连接超时或 ECONNRESET | 节点质量、规则命中、策略组切换 | 固定稳定节点，确认相关域名没有误走 DIRECT。 |
| 域名解析失败 | Clash DNS、fake-ip、其他 VPN | 先恢复默认 DNS 配置，再用日志定位具体域名。 |
| 登录成功但补全不可用 | Copilot API 域名、插件版本、帐号权限 | 查看扩展日志，区分网络错误与 401/403 权限错误。 |
一套不绕路的完整排障顺序
当你无法判断到底是 Clash、IDE 还是 GitHub 帐号的问题时，可以按下面顺序做一次干净测试。每完成一项就记录结果，不要同时修改五个开关，否则即使问题消失，也无法知道真正有效的改动是什么。
- 确认帐号状态：在浏览器中打开 GitHub，确认帐号能正常登录，并检查 Copilot 订阅或组织授权没有过期。
- 固定节点：在 Clash 中选择一个延迟稳定、近期访问 GitHub 正常的节点，暂时不要使用自动切换组。
- 测试代理端口：用
curl通过本机混合端口访问 GitHub 和 API，确认 Clash 至少能建立基础 HTTPS 连接。 - 观察连接日志：重新从 IDE 发起登录，记录实际域名、命中的规则、策略组、连接状态和错误码。
- 修正规则顺序：把确认属于 Copilot 链路的域名规则放在宽泛直连、GEOIP 和最终匹配规则之前。
- 检查 IDE 代理：清理 VS Code 或 JetBrains 中失效的手动代理，确保其代理地址和 Clash 当前端口一致。
- 处理本机回调：确认
localhost与127.0.0.1不被代理，防火墙没有拦截授权回调。 - 最后再测试 TUN：只有在 IDE 明显不遵守系统代理时才启用 TUN，并逐项确认路由、DNS 和虚拟网卡状态。
如果更换节点后仍然只有某个组织帐号失败，而公共 GitHub 页面、API 和 Copilot 连接都能在日志中稳定完成，那么继续改 Clash 的意义就不大了。此时应检查组织是否限制 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，还要继续换节点吗？
如果连接已经完成 TLS 握手并稳定到达服务端，401 或 403 更可能与 Token、帐号授权、Copilot 订阅、组织策略或插件状态有关。可以先退出并重新登录、更新插件并检查帐号权限；只有当日志同时出现超时、连接重置或规则误命中时，才继续从 Clash 网络链路排查。
相比之下，一些仅提供浏览器代理开关的同类工具，遇到 GitHub Copilot 这类同时涉及浏览器授权、IDE 后台进程、本机回调和长连接请求的场景时，往往缺少清晰的连接日志与规则命中信息，用户只能反复切换节点或重装插件。Clash 官网 更适合把混合端口、规则组、TUN、DNS 和连接日志放在同一套排障思路中逐项核对，既能保留规则模式的可控性，也方便为 VS Code、JetBrains 等不同开发环境建立稳定配置；如果你正准备按本文流程定位 Copilot 登录超时，不妨免费下载 Clash 官网，先用固定节点和日志观察把问题跑通，再逐步恢复自动测速与更复杂的分流策略。