GitHub连接异常排查：DNS、TLS、Git代理与认证问题一次梳理
GitHub 进不去，表面上是网页打不开，实际可能发生在不同层级：域名没有解析、TCP 连接超时、TLS 握手失败、浏览器扩展干扰、企业网络策略拦截，或者 Git 本地配置残留了错误的代理。网页能打开但 git clone 失败，也不一定是同一个故障。
本篇文章按照可复现、可回滚的方式，拆解浏览器访问、Git HTTPS、Git SSH 三条链路。命令均使用示例域名和占位仓库，实际操作时替换为自己有权限访问的项目。
一、区分网页访问与 Git 操作
浏览器会加载页面脚本、验证码和静态资源；Git HTTPS 主要访问远端仓库接口；Git SSH 则涉及独立的主机和端口。三个最小测试如下：
nslookup github.com curl.exe -I -L --connect-timeout 5 --max-time 15 https://github.com/ git ls-remote https://github.com/OWNER/REPO.gitnslookup 失败，故障更接近 DNS 或本地网络配置；curl 在连接阶段超时，重点检查网络出口、防火墙和代理；curl 能收到 HTTP 响应但 Git 失败，问题可能落在凭据、仓库权限或 Git 配置；git ls-remote 能返回引用列表，说明 HTTPS 到仓库的基本链路和权限至少满足当前操作。
不要用 ping 是否成功作为唯一判断。ICMP 可能被网络设备或服务器策略过滤，而 HTTPS 仍然可以正常工作。
二、DNS解析异常怎么确认
浏览器提示“无法访问此网站”、Git 报 Could not resolve host，都可能与 DNS 有关。Windows 可以使用：
Resolve-DnsName github.com Resolve-DnsName api.github.com重点观察是否能返回记录、同一网络下是否反复出现异常结果，以及其他常用域名能否正常解析。只查询 github.com 还不够，因为登录、API、代码下载和静态资源可能使用不同域名。
本地缓存异常时，可以刷新后重新测试：
ipconfig /flushdns如果设备处于公司、学校或云桌面网络，DNS 由组织统一管理时，不建议私自修改系统配置。也不建议把网上找到的旧 IP 写入 hosts 文件：服务端地址会变化，证书仍按域名校验，过期映射会让问题更难定位。
三、TLS握手失败的排查路径
DNS 有结果，并不代表 HTTPS 已经建立。使用 verbose 模式观察解析、连接、证书和响应阶段：
curl.exe -vI --connect-timeout 5 --max-time 15 https://github.com/Failed to connect 或 Operation timed out 表示 TCP 连接没有按时完成；SSL_ERROR_SYSCALL 或 handshake failure 需要检查 TLS、代理转发、证书链和中间设备；certificate verify failed 应检查系统时间、根证书和企业 HTTPS 检查配置，不要直接关闭证书验证；收到 HTTP/2 200、301 等 HTTP 响应，说明 TLS 至少已经完成，问题应转向 HTTP 或应用层。
企业网络如果使用安全网关检查 HTTPS，客户端需要安装组织提供的受信任根证书，并按公司流程配置。不要把证书校验改成全局关闭。
四、检查Git是否残留错误代理
浏览器使用的是系统代理，不代表 Git 自动继承了正确配置。Git 的配置可能来自系统级、全局级、本地仓库级和环境变量，可以先列出来源：
git config --show-origin --get-regexp '^(http|https)\\..*proxy$' Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue如果输出了已经停用的本地端口、旧服务器或格式错误的地址，Git 可能在连接 GitHub 前被导向错误的中间层。确认全局配置无效后，再按来源删除：
git config --global --unset-all http.proxy git config --global --unset-all https.proxy以上命令只处理全局 Git 配置。如果问题来自当前项目的 .git/config，应在项目目录中使用 --local；如果来自系统配置，需要由管理员处理。企业网络确实要求 HTTP 代理时，应填写组织提供的代理地址，并确认代理允许 CONNECT 到目标端口，不能照抄网上的随机端口示例。
五、Git HTTPS与SSH要分开测试
HTTPS 远端可以用只读命令验证：
git remote -v git ls-remote origin不要把账号密码或访问令牌直接写进 URL，因为它们可能进入 Shell 历史、日志或 .git/config。
SSH 连接使用另一套配置：
ssh -T git@github.com ssh -vT git@github.com如果公司网络只允许经过审批的 443 端口，并且组织策略允许 SSH over HTTPS，可以按照 GitHub 官方文档配置 ssh.github.com:443。这不是通用修复方法，使用前要确认企业防火墙和账号策略允许该方式。只需要拉取公开仓库时，HTTPS 往往更容易定位。
六、403、404和认证失败不能混为一谈
401 或认证提示通常表示客户端没有提供有效凭据，或者凭据已经过期。检查 Git Credential Manager、系统凭据管理器和登录状态，不要在远端 URL 中保存令牌。
403可能是仓库权限不足、组织策略限制、令牌权限范围不够，也可能来自网络网关。可以用浏览器确认当前账号是否能看到仓库，再用 git ls-remote 做只读测试。只有某个组织仓库失败时，优先查看仓库授权和组织策略；多个目标都失败时，再检查网络出口和 Git 配置。
404并不一定表示网络不通。对于私有仓库，未登录或无权限时，服务端可能不直接暴露资源是否存在。此时应检查仓库路径和账号授权。
七、验证码或页面资源加载不完整
页面部分打开、登录按钮无响应或验证码一直加载，常见原因包括 JavaScript 被禁用、浏览器扩展修改请求、企业安全网关拦截验证码域名，以及浏览器版本过旧。可以做以下检查：
- 使用受支持的浏览器并更新到当前稳定版本；
- 在无痕窗口中临时测试，排除缓存和扩展影响；
- 只对 GitHub 官方文档要求的验证码域名检查连通性；
- 如果设备属于组织网络，把失败时间和错误摘要交给管理员。
不要通过关闭浏览器安全功能、安装来源不明的“修复插件”或复制脚本修改系统网络设置来解决验证码问题。
八、按错误现象建立排错表
| 现象 | 可能层级 | 建议动作 |
|---|---|---|
| Could not resolve host | DNS | 检查解析、缓存和组织 DNS 策略 |
| Failed to connect / timed out | TCP、出口或防火墙 | 用 curl -v 区分连接阶段，检查代理与防火墙 |
| TLS 握手或证书错误 | TLS、中间设备或系统时间 | 核对时间、根证书和企业 HTTPS 检查 |
| 网页正常，Git 失败 | Git 配置、凭据或远端地址 | 检查 git config、git remote -v 和凭据管理器 |
| HTTPS 正常，SSH 失败 | SSH 主机、端口或密钥 | 使用 ssh -vT，核对密钥和组织允许的端口 |
| 403 / 404 | 权限、仓库路径或组织策略 | 在账号权限与网络网关两侧验证 |
九、不要把高风险操作当作通用修复
有些教程把修改 hosts、关闭 http.sslVerify、在命令中写入明文令牌当作通用方案。这些操作会掩盖真实问题，甚至扩大安全风险：固定旧 IP 可能导致证书不匹配；关闭证书验证会失去 HTTPS 身份校验；明文令牌可能被历史记录和日志泄露；不明来源脚本可能修改代理、证书或系统网络设置。
更稳妥的做法是保留原始错误、使用官方诊断工具、确认组织网络策略，并让每一步配置都可以回滚。
十、总结
GitHub 连接异常的排查重点不是不断更换设置，而是确定故障边界：解析失败看 DNS，连接超时看 TCP 和网络出口，TLS 错误看证书与中间设备，Git 失败看代理配置、远端地址和认证权限。网页、HTTPS Git 和 SSH 需要分别测试，不能用一个结果替代全部判断。
完成最小复现后，把命令、时间、网络位置和脱敏后的错误信息整理出来，通常就能判断问题属于本机、组织网络、Git 配置，还是仓库权限，后续处理会更准确。
参考资料
- GitHub 官方：Troubleshooting connectivity problems
- GitHub 官方：Using SSH over the HTTPS port