GitHub 进不去，先找出卡住的请求
我处理 GitHub 访问问题，会先把“打不开”拆开。首页无法显示、仓库能看却拉不下来、正文出现但图片空白，排查入口各不相同。把它们混成节点问题，容易反复换线路，却留下更多互相干扰的设置。
我没有这条线路在你电脑上的测试记录，也不会凭报错就断言域名遭到阻断。你可以先记下失败的操作、完整报错，以及客户端当时采用的模式。后面的每次修改，都用原来的操作复查。
终端拉不动该改哪里
Git 命令行的连接是否经过代理，需要单独核对；浏览器打开仓库不能证明终端路径正确，我会先查本地入口再改配置。
先确认客户端已经运行，并在设置里找到实际使用的代理协议和监听端口。下面的地址只是配置示例，不能用来推断 Clash Verge Rev 或 v2rayN 在你电脑上的设置。端口不同，命令也要相应调整。
客户端界面不熟悉，可以先看 Clash Verge Rev 的配置方法。我建议先弄清入口，再粘贴命令；客户端没有接收请求，Git 配置写得再完整也没有用。
使用 HTTP 代理入口时，可以参考：
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897
如果客户端提供的是下面这种代理入口，则参考另一组写法：
git config --global http.proxy socks5://127.0.0.1:10808
git config --global https.proxy socks5://127.0.0.1:10808
这两组是替代关系，按实际入口选用。不要把它们连续执行，再把后面的覆盖当成额外加速。地址里的协议也要与客户端提供的入口对应，不能只看端口相同。
写入后，查看 Git 当前保存的代理：
git config --global --get http.proxy
返回地址符合预期，再重试刚才失败的 git clone。我会保持仓库和客户端模式不变，只检查这次配置是否改变了现象。若同时换节点、换仓库、换网络，就很难知道哪项修改起了作用。
这些命令修改的是全局配置，之后使用其他仓库也可能受到影响。客户端关闭后突然无法拉取，旧代理地址就是值得检查的地方。需要撤回时执行：
git config --global --unset http.proxy
git config --global --unset https.proxy
TUN 模式也是排查方向，但开启开关不等于请求已经按预期转发。你仍要检查接管范围和分流规则。显式代理已经生效时，不必为了追求更多开关再叠加配置；先保留能够解释清楚的路径。
网页有了图片为何空白
GitHub 页面正文与图片可能经过不同的请求路径，正文能显示不代表资源域名可访问，我会分别检查域名规则和解析设置。
头像、仓库说明里的图片、页面内嵌资源，可以分开观察。先判断是某张图片失效，还是多个仓库都出现类似情况。前者也可能是资源本身的问题，不能看到空白就认定整条网络路径有故障。
排查时可以留意 raw.githubusercontent.com 和 avatars.githubusercontent.com。它们是这里需要检查的资源域名，并不意味着所有图片都由这些地址提供。你应以失败请求实际使用的域名为准。
我会先检查客户端如何处理这些请求，再考虑改 DNS。规则只覆盖 github.com，并不能据此认定 *.githubusercontent.com 也走了相同路径。已有规则分组的名字同样不能代替实际命中情况。
图片请求该怎么查
先保留当前设置，重新加载出问题的页面，查看客户端是否出现对应资源请求。若能看到请求，继续核对它采用的规则与出口；若看不到，就回到客户端是否接管这次访问的问题。
DNS 和 DoH 可以作为解析环节的检查方向，但不要把启用 DoH 当作图片恢复的保证。解析地址之后仍然需要建立连接；解析设置改变了，后续路径未必跟着改变。
我不建议照搬来源不明的固定地址映射。这样的改动可能暂时改变表现，也会增加后续排障的变量。已经手动改过解析设置，就记录改动内容，并准备好恢复方式。
只修复图片问题时，尽量不要顺手改动全部应用的网络路径。若网页和终端都出错，可以按 国外网页打不开的排查顺序 先检查共同环节。
依赖下载也归代理管吗
开发工具下载失败时，应先确认实际请求的资源与执行环境，再决定调整代理还是使用镜像，我不会只凭超时提示更换来源。
仓库代码、安装依赖、下载模型可能发生在同次操作里，却不一定访问同个服务。你看到的是整体任务失败，真正失败的可能只是其中某项下载。先找到报错前后的资源信息，比直接重装工具更有价值。
| 遇到的提示 | 先核对什么 | 调整方向 |
|---|---|---|
fetch failed: connect ETIMEDOUT | 哪个依赖请求超时，当前进程如何连接 | 查代理入口，再考虑镜像 |
HTTP error 403 / Connection reset | 拒绝访问与连接中断分别发生在哪里 | 保留完整错误，分别处理 |
spawning cargo-fetch failed | 前后日志是否说明了失败原因 | 不凭提示片段确定原因 |
huggingface_hub.utils.HfHubHTTPError | 资源访问条件与连接路径 | 按工具说明核对配置 |
镜像是另一个资源来源，不是“网络修复”的同义词。更换前，要确认来源说明、资源是否齐全，以及之后如何恢复。镜像能下载某项依赖，也不能证明 GitHub 的网页访问已经恢复。
同样，不要把 Git 的代理配置直接当作其他开发工具的配置。不同工具是否读取相同设置，要分别确认。你可以保留 Git 已经有效的配置，再处理当前失败的工具，避免修好依赖却弄坏仓库访问。
有些报错涉及访问权限。遇到拒绝提示时，我会先核对资源是否允许当前账号访问，而不是连续换出口。报错文案只是线索，完整日志和发生环境才决定下一步该查哪里。
开发连接故障怎么判断
GitHub 相关故障要按连接路径、资源下载和账号权限分别判断，我会用下面的问题缩小范围，避免拿同套设置处理所有报错。
网页能开为何拉取失败
浏览器访问成功，只能说明这次网页请求完成了。终端是否采用代理、Git 保存的地址是否仍然有效，都需要另查。
先回到前面的配置查询，核对 http.proxy 与客户端当前入口。如果地址正确，再看分流方式。不要因为网页正常，就跳过终端路径直接重装 Git。反过来，命令行拉取成功，也不能证明浏览器的图片规则没有遗漏。
SSH 拉取超时怎么查
SSH 拉取需要检查自己的连接方式。前面写入的 HTTP 代理设置，不能直接作为这条路径已经生效的依据。
事实材料中的 ~/.ssh/config 示例使用 ProxyCommand 转发连接，但它需要配套工具和匹配的本地入口。我不建议在没有确认这些条件时直接粘贴。先确认你能解释配置里的每项参数，再按所用工具的说明操作。
若不清楚现有文件用途，先保存原配置。网络超时与身份验证失败也要分开看，改代理不能替代权限检查。
附件下载慢怎么判断
下载 .zip 或 .exe 时，先观察是始终没有开始，还是已经下载但进度缓慢。首页打开很快，不足以说明附件请求也经过相同路径。
我会固定同个附件，对比客户端不同出口的表现，并检查请求是否按预期转发。不要仅凭某次下载慢就购买更贵的套餐，也不要把 IEPL 当成附件下载表现的保证。这里没有可以支持这种承诺的数据。
证书报错能跳过吗
证书校验报错不该靠长期关闭校验来掩盖。关闭后即使请求继续执行，也不能据此认定原问题已经修复。
我会先保留完整提示，检查最近是否改过代理、证书或相关工具配置，再按对应软件说明处理。不要复制不明教程里的关闭校验命令，也不要把它写进日常配置。若之前已经改过，应按 Git 文档恢复校验设置，再继续定位原因。
Copilot 连不上查什么
Copilot 连接失败时，可以检查 *.githubcopilot.com 与 *.api.github.com 的规则处理情况。只确认 GitHub 首页能打开，证据还不够。
如果客户端采用 TUN 模式，还要确认相关请求是否被接管。规则看起来齐全但功能仍失败，就继续核对客户端之外的应用设置。这里不把所有连接失败都归到 WebSocket，也不凭提示猜测账号状态。
Actions 下载失败怎么查
Actions 任务中的失败，要从任务日志和实际运行环境查起。你电脑上的代理入口，不能直接解释另一个环境里的连接行为。
先找到具体失败的依赖请求，再检查任务中的资源来源、权限与网络配置。不要把本地代理地址照抄进去，也不要假定运行位置就能保证下载顺畅。镜像是否合用，应按任务所需资源判断。
推送被拒该换节点吗
推送被拒时，我会先读权限提示。连接超时和没有写入权限，是不同问题，换节点不一定改变后者。
核对当前使用的身份、目标仓库和授权情况，再看网络路径。不要仅凭拒绝提示就断言账号触发了异地登录判断，也别急着删除原来的密钥。先确定拒绝发生在哪个环节，再改对应设置，回退也会更容易。
Mac 更新下载怎么查
Mac 上的工具更新缓慢，同样要确认终端实际采用的连接方式。浏览器走代理，并不能替代这项检查。
如果你准备修改 ~/.zshrc，先确认文件里已经有哪些相关设置。旧地址和新配置同时存在，会让后面的判断更困难。具体客户端操作可以看 Mac 客户端与代理设置，涉及工具自身的镜像配置则以官方说明为准。
镜像拉取重试怎么查
镜像拉取出现 error pulling image: dial tcp timeout 时，先确认执行下载的组件与它采用的代理配置。终端里能连接，不足以证明负责拉取的组件也能连接。
配置入口和生效方式要按实际软件确认，我不在这里给未经核对的菜单路径。保留完整报错，改动后重新执行原任务；若错误发生变化，再沿新的线索继续查，不要不断叠加设置。
节点地区该怎么选
我没有能支持地区排名的下载记录，因此不会给你承诺哪个地区一定更快。地区名称只能帮助识别出口，不能替代你的任务表现。
用同个仓库、同种操作比较候选出口，观察能否完成、是否中途断开，以及失败后能否重复出现。测试期间尽量保持其他条件不变，才有依据判断换出口是否有用。
如果节点本身持续超时，先按 节点超时的检查方法 排查。价格和知名度都不能替你回答这次连接为何失败。需要服务商协助时，我会看客服是否读懂报错、能否给出具体检查步骤，以及回复是否及时。