遇到 GitHub 连接超时时，很多人第一反应是更换节点、重启路由器，甚至重新安装 Clash。但如果浏览器、git clone、Release 文件下载都表现为长时间等待，问题未必出在节点本身，也可能是请求没有进入代理、规则把 GitHub 判成了 DIRECT，或者 DNS 解析结果与当前代理模式不匹配。尤其是在 Clash Verge Rev、Clash for Windows、ClashX 或 Mihomo 客户端中，系统代理、终端代理和 TUN 接管属于不同层级，不能简单理解为「打开代理后所有程序都会自动走节点」。
本文按照「先确认现象，再检查代理，再核对规则，最后处理 DNS 与 TUN」的顺序展开。你不需要一开始就修改大量 YAML，也不必看到一次超时就认定订阅失效。只要能在 Clash 的连接记录中确认 GitHub 请求实际命中的域名、策略和节点，通常就能把问题缩小到几个明确的范围。以下内容适用于 GitHub 网页、git clone、git pull、Raw 文件、Release 附件以及部分 GitHub API 请求。
先判断：GitHub 超时究竟发生在哪一层
GitHub 超时并不是一种单一错误。浏览器显示「网页无法打开」、Git 返回 Failed to connect、命令行出现 Connection timed out，虽然都像网络故障，但每一种现象对应的排查入口可能不同。先记录失败动作和完整错误信息，不要只保留「打不开」这三个字。你可以分别测试主页、代码仓库、Raw 文件和 Release 下载，因为它们往往使用不同的主机名。
- 网页主页超时：常见目标是
github.com，重点检查系统代理、浏览器代理和基础规则。 - 仓库页面能打开，但图片或脚本加载失败：可能涉及
github.githubassets.com、githubusercontent.com等关联域名，说明规则覆盖不完整。 - Raw 文件打不开：重点观察
raw.githubusercontent.com的策略命中情况，不能只测试github.com。 - Release 下载卡住：下载链接可能跳转到对象存储或 CDN 域名，面板中显示的最终主机名不一定是 GitHub 主域。
git clone失败而浏览器正常：通常与 Git 没有继承系统代理、HTTPS 代理端口填写错误，或 SSH 与 HTTPS 使用了不同链路有关。
在 Clash Verge Rev 的「连接」或「Connections」面板中复现一次失败请求，然后搜索 github、githubusercontent 和 git。如果完全没有记录，说明请求可能没有经过当前 Clash 内核，或者程序使用了独立的网络通道；如果能看到记录，则重点查看 Policy、连接状态和目标端口。记录显示 DIRECT 并不一定代表配置错误，但如果你的本地网络无法稳定访问 GitHub，这个结果就足以解释超时。
| 现象 | 优先检查项目 | 不要先做的事 |
|---|---|---|
| 浏览器和 Git 都超时 | Clash 是否运行、系统代理是否开启、节点是否可用 | 直接重写整份配置 |
| 浏览器正常，Git 超时 | Git 的 HTTPS_PROXY、代理端口和协议 | 反复刷新浏览器页面 |
| github.com 正常，Raw 超时 | 规则是否覆盖 raw.githubusercontent.com | 只更换 GitHub 主站节点 |
| 连接命中代理仍很慢 | 节点延迟、TLS 握手、DNS 模式和出口质量 | 无限调大 Git 的超时时间 |
检查 Clash 代理状态：系统代理、端口与策略
第一步是确认 Clash 客户端本身处于运行状态，并且当前配置已经成功加载。打开 Clash Verge Rev 或 Mihomo 客户端，先看内核是否为 Running，再确认当前使用的配置没有红色错误提示。订阅更新成功不等于配置一定可用：有些配置在更新后策略组名称发生变化，旧的覆写规则可能失效；有些节点虽然出现在列表中，但实际连接已经被服务端拒绝。
接下来检查代理模式。排查 GitHub 超时期间，建议暂时使用规则模式，而不是一上来就长期使用全局模式。规则模式便于在连接面板中观察每个域名的命中策略，也能避免企业内网、局域网打印机和国内代码仓库被不必要地送入代理。为了做一次明确的对照测试，可以短暂切换到全局模式，刷新 GitHub 页面或执行一次轻量的 git ls-remote。如果全局模式成功、规则模式失败，故障重点就落在规则顺序或规则集覆盖范围，而不是节点完全不可用。
同时确认客户端的 mixed-port 或 HTTP 代理端口。常见本地端口可能是 7890、7897 或其他自定义值，但不能照抄示例。端口必须以客户端「设置」「端口」页面显示的实际值为准。对于浏览器，打开系统代理开关后，系统通常会自动写入 HTTP 与 HTTPS 代理；对于终端工具，则需要显式告诉程序代理地址。可以先用本机回环地址测试端口是否在监听：
curl -I -x http://127.0.0.1:7890 https://github.com
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/OWNER/REPOSITORY.git如果第一条命令成功，而普通浏览器访问仍超时，说明浏览器没有使用同一个代理；如果第一条成功、第二条失败，则要继续检查 Git 配置、仓库地址和认证方式。若两条都失败，回到 Clash 连接面板确认是否出现请求，再测试另一个节点。使用 curl -I 的价值在于它能快速验证 HTTPS 握手，而不需要等待完整网页、图片和脚本全部加载。
http.proxy 必须使用与协议相匹配的端口；如果端口只支持 SOCKS，却写成 http://127.0.0.1:端口，通常会出现连接被重置或握手失败。
修正规则与 DNS：避免 GitHub 被误判为直连
当连接面板确认 GitHub 请求命中了 DIRECT，可以先检查规则顺序。Clash 采用从上到下的匹配逻辑，靠前的规则优先级更高。如果前面存在宽泛的 GEOIP,CN,DIRECT、某个过大的 IP 规则集，或订阅提供商将 GitHub 相关地址归入了直连集合，那么后面再添加一条代理规则也可能完全不会生效。自定义规则应放在明确的覆写位置，并确认客户端确实启用了该覆写，而不是只保存了文件却没有重新载入。
排查时可以先针对常见主机名添加精确规则，再根据连接记录逐步扩展。常见写法如下，策略组名称需要替换成你自己的代理组：
rules:
- DOMAIN,github.com,PROXY
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,githubassets.com,PROXY这里的重点不是机械复制这些条目，而是理解它们的范围。DOMAIN,github.com 只匹配主域；DOMAIN-SUFFIX,github.com 可以覆盖相关子域；githubusercontent.com 负责 Raw 内容及部分用户内容分发；githubassets.com 则可能承载页面静态资源。不要为了省事直接把所有流量设为全局代理，也不要随意加入不相关的第三方域名。修改后重新载入配置，再在连接面板中确认每条请求的策略已经变成目标代理组。
DNS 是另一个容易被忽略的环节。即使 TCP 流量最终通过代理发送，域名解析仍可能先由本地运营商 DNS 完成。如果解析结果受到污染、返回不可达地址，或者 fake-ip、redir-host 与 TUN 的配置互相冲突，表现就可能是偶发超时：有时 GitHub 能开，有时同一个地址等待几十秒。Clash 的 DNS 设置应尽量保持一致，避免浏览器使用 DoH、系统使用运营商 DNS、终端又通过另一个本地服务解析，造成不同程序得到不同结果。
如果你开启了 fake-ip，发现某个 GitHub 域名持续失败，可以暂时观察是否存在 fake-ip 过滤、fake-ip 网段冲突或局域网 DNS 劫持。若企业 VPN、广告拦截器、网卡安全软件也在接管 DNS，建议一次只保留一套主要解析路径进行测试。修改 DNS 后需要重新打开连接，必要时清理系统 DNS 缓存，再比较前后结果。DNS 调整不能替代节点测试：若域名解析正常、请求也命中代理，但 TLS 仍在多个节点上失败，应继续查看出口质量或远端服务状态。
动手修复 Git：让 clone、pull 和下载走同一代理
浏览器能访问 GitHub，并不代表 Git 命令会自动使用 Clash。Git 可能运行在独立终端、VS Code 集成终端、脚本任务或 CI 服务中，每种启动方式继承的环境变量都可能不同。建议先在即将执行 Git 命令的同一个终端里检查代理变量，再使用临时参数做最小范围测试。这样不会立即改变全局配置，也方便判断问题是否确实来自 Git 的代理链路。
临时测试 HTTPS 代理
在 macOS、Linux 或支持类似 shell 语法的环境中，可以为当前会话设置代理：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,.local
git ls-remote https://github.com/OWNER/REPOSITORY.gitWindows PowerShell 可以使用对应的环境变量写法：
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
git ls-remote https://github.com/OWNER/REPOSITORY.git如果命令成功，说明 GitHub 链路和当前代理基本可用，接下来可以决定是否保存为 Git 的持久配置。持久配置适合长期在同一台电脑上开发，但公共电脑、公司网络和经常切换代理端口的设备不建议永久写死。需要移除时，可以检查 ~/.gitconfig 或运行 git config --global --unset http.proxy 与 git config --global --unset https.proxy。如果仓库地址是 SSH 格式的 [email protected]:OWNER/REPOSITORY.git，上面的 HTTPS 代理变量通常不能直接解决 SSH 连接；最省事的排查方式是先改用 HTTPS 仓库地址，确认下载链路后再单独配置 SSH。
检查 Git 配置与 VS Code 终端
Git 可能已经保存了一条旧代理，例如指向已经关闭的 127.0.0.1:1080。可以使用以下命令查看当前生效来源：
git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'
env | grep -i proxyWindows 用户可以使用 Get-ChildItem Env: | Where-Object Name -Match "PROXY" 查看环境变量。若输出中同时存在环境变量、全局 Git 配置和仓库级配置，优先确认它们是否指向同一个端口。VS Code 集成终端还可能没有重新加载修改后的 shell 配置，关闭旧终端并新建一个会话后再测试。对于由任务、扩展或后台服务启动的 Git 操作，不能只看可见终端；应在对应进程的环境设置中配置代理，或者临时使用已经验证成功的 HTTPS 地址。
下载 Release 附件时，如果浏览器可以打开页面但点击下载一直卡住，请在连接面板中查看跳转后的最终域名。部分附件会转到不同的 CDN 或对象存储地址，此时应以真实日志为准补充规则。规则调整后不要只刷新当前页面，最好重新发起一次下载并观察新的连接记录，确认新增域名没有再次命中 DIRECT。
何时启用 TUN：最后处理顽固进程与节点问题
如果系统代理和显式 Git 代理都能验证成功，但某个独立程序仍然不读取代理变量，可以考虑启用 Clash 的 TUN 模式。TUN 在网络层接管更多未主动配置代理的程序，适合某些内置网络栈、后台同步器或开发工具。但它不是越早开启越好：TUN 可能与企业 VPN、Docker 网桥、虚拟机网卡、杀毒软件过滤驱动发生冲突，也可能改变局域网访问和 DNS 路径。启用前建议记录当前可用配置，开启后只测试 GitHub、内网和常用网站三类目标。
如果 TUN 开启后 GitHub 仍超时，先确认「自动路由」「严格路由」和 DNS 劫持选项是否与当前系统兼容，再查看连接记录是否出现重复连接或错误网卡。不要同时启动两个 Clash 客户端，也不要让旧版 VPN 和 Clash 同时修改默认路由。对于仅需要浏览器和 Git 的电脑，规则模式加显式 HTTPS_PROXY通常比 TUN 更容易维护；只有在确认某个程序完全不支持代理、且你能接受虚拟网卡带来的副作用时，才值得保留 TUN。
节点方面，建议用三个维度判断，而不是只看测速延迟：第一是 HTTPS 握手是否能稳定完成，第二是 GitHub 页面、Raw 和 Release 是否都能持续请求，第三是长时间下载时是否频繁重置。低延迟节点不一定适合 GitHub，跨境链路的丢包、出口限速和晚高峰拥塞都会影响实际体验。测试时固定同一域名和同一个文件，逐个切换节点并观察连接面板，才能得出有意义的结论。
与只依赖浏览器代理扩展的方案相比，Clash 的优势在于可以把浏览器、Git、Raw 文件和 Release 下载放进同一套可观察的规则链路；与单纯全局 VPN 相比，规则模式又能保留内网和国内服务的直连路径，减少不必要的绕路。某些轻量代理工具配置入口少，遇到 GitHub 子域、DNS 分流或终端不继承代理时往往只能反复重启；Clash 则能通过连接日志、策略组、覆写规则和可选 TUN 逐层定位。如果你希望在不同平台上复用这套排查思路，可以根据设备选择合适的 Clash 客户端并从下载页开始准备。