Windows 代理设置后 GitHub 打不开怎么办？

更新于 2026-11-01 · ghproxy.cyou

简答：Windows 代理设置后 GitHub 仍打不开，先不要反复切换开关：先确认代理软件正在运行、HTTP 或混合端口可用，再分别检查浏览器、Git 和 WinHTTP 是否使用了不同配置。若浏览器能打开而 Git 失败，优先清理 Git 的 http.proxy 或环境变量；若所有程序都失败，再查代理端口、DNS、防火墙、企业网络和证书。

定义：Windows 代理故障排查，是把系统代理、WinHTTP、环境变量、Git 独立配置和网络链路分开验证，以确定到底是哪一层没有生效。

先试这一步：一分钟判断故障在哪一层

本文是第三方使用指南，目标是帮助你排查 Windows 代理设置后 GitHub 无法打开的问题，不代表任何相关服务或网站的官方页面。先按下面顺序测试，成功标准是页面能正常返回、Git 能建立 HTTPS 连接，并且连续重复测试时结果基本一致。

GitHub 文档指出，连接问题常见原因包括防火墙、代理服务器和组织网络配置；如果只在企业或学校网络中失败，应先确认网络规则是否阻断了 GitHub。可参考 GitHub 连接问题排查文档。

第 1 步：确认代理软件、端口和协议类型

1. 确认代理软件处于运行状态。打开客户端的连接日志或运行状态页，查看是否有本地监听端口。常见端口形式是本机地址加端口号，例如 127.0.0.1:端口，具体数值以当前客户端界面为准。
2. 确认使用的是 HTTP、HTTPS 或混合端口。浏览器和 Git 的 HTTPS 请求通常需要一个能处理 HTTP CONNECT 的代理入口。不要把 SOCKS 端口直接当作 HTTP 端口填写，除非当前软件或应用明确支持该协议。
3. 先做本机端口测试。在 PowerShell 中运行 Test-NetConnection 127.0.0.1 -Port 端口号，把“端口号”替换为客户端显示的端口。若 TcpTestSucceeded 为 False，说明本地端口没有正常监听，先回到客户端检查开关、端口冲突或权限。
4. 重新启动使用代理的应用。部分程序只在启动时读取环境变量或代理配置。GitHub 的代理文档也说明，相关代理环境变量在应用启动时读取，配置变化后需要重启应用。

如果本机端口测试失败，不要继续修改 Git 配置；先修复客户端监听问题。端口测试成功也不等于 GitHub 一定可用，还要继续验证目标连接。

第 2 步：分别验证浏览器、GitHub API 与 Git HTTPS

不要只打开 github.com 就判断代理正常。浏览器页面、API、原始文件和 Git HTTPS 可能经过不同的应用配置或连接路径。

1. 在浏览器无痕窗口打开 https://github.com，排除扩展、缓存或登录状态干扰。
2. 尝试打开 https://api.github.com。如果页面能返回 JSON 或接口响应，说明至少有一条 HTTPS 路径可达。
3. 尝试打开 https://raw.githubusercontent.com，用于区分网页访问与原始文件访问是否都正常。
4. 在 PowerShell 中执行 curl.exe -I https://github.com。注意这里使用的是 Windows 自带的 curl 命令行程序，结果只用于观察响应和连接错误，不代表 Git 已经使用同一代理。
5. 如果要测试 Git，使用一个你有权限访问的仓库执行 git ls-remote https://github.com/用户/仓库.git，把地址替换为实际仓库。成功标准是返回引用信息，而不是仅仅出现登录提示。

如果网页正常、git ls-remote 失败，问题大多在 Git 自身的代理、证书、凭据或环境变量；如果网页和命令行都失败，优先回到本地端口、系统代理、DNS 或网络限制排查。

第 3 步：检查 Windows 系统代理、WinHTTP 与环境变量

Windows 系统代理和 WinHTTP 不是完全相同的配置入口，使用 WinHTTP 的应用或服务可能不会自动读取浏览器当前代理。GitHub 文档说明，Windows 环境可以通过环境变量或 netsh 配置代理；Microsoft 文档则明确区分了 WinHTTP 的查看、导入、设置和重置操作。

1. 查看 WinHTTP 配置。以普通权限打开命令提示符，运行 netsh winhttp show proxy。如果显示了已经失效的代理地址，记录后再判断是否需要清理。
2. 清除错误的 WinHTTP 代理。确认当前网络不需要该配置时，运行 netsh winhttp reset proxy，它会将 WinHTTP 代理重置为直连。执行后重新打开相关应用再测试。
3. 查看环境变量。在 PowerShell 中运行 Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }，检查是否存在 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或 NO_PROXY。旧地址、错误端口和过期认证信息都可能让命令行继续走错误代理。
4. 不要盲目同时配置多层代理。如果系统代理、WinHTTP、环境变量和 Git 都填写了不同地址，先保留一套确定可用的配置，其他层暂时清理或恢复默认，再进行测试。

Microsoft 的 netsh winhttp 文档提供了 show proxy、reset proxy、set proxy 和高级代理配置的说明；其中具体命令是否适用于某个应用，取决于该应用是否使用 WinHTTP。

第 4 步：清理或修正 Git 独立代理配置

Git 可以通过 http.proxy 覆盖环境变量中的代理设置，因此“浏览器能打开、Git 打不开”时，应优先查看 Git 的有效配置来源。Git 官方文档说明，http.proxy 可以覆盖 http_proxy、https_proxy 和 all_proxy 环境变量。

1. 查看配置来源。运行 git config --show-origin --get-regexp "(^|\.)proxy$|ssl"。如果命令没有输出，不代表没有环境变量代理，还要继续查看系统环境变量。
2. 查看全局代理。运行 git config --global --get http.proxy 和 git config --global --get https.proxy。
3. 删除过期的全局代理。确认不再使用旧代理时，运行 git config --global --unset http.proxy 和 git config --global --unset https.proxy。如果提示没有该配置，可以继续下一步。
4. 检查仓库级配置。进入项目目录，运行 git config --local --get-regexp "proxy|ssl"。仓库级设置可能覆盖全局设置，必要时使用 git config --local --unset http.proxy 清理。
5. 重新测试。运行 git ls-remote https://github.com/用户/仓库.git。不要只看 Git 配置页面显示成功，必须确认目标仓库请求确实返回结果。

如果代理需要认证，不建议把长期密码直接写进 URL 或脚本。Git 文档列出了代理认证方式，并提醒涉及基本认证时应使用加密连接，避免凭据以明文暴露。相关字段可参考 Git config 官方文档。

第 5 步：按错误信息分流处理

这些错误只能作为定位线索，不能单凭一条错误判断唯一原因。尤其是超时、502 和连接重置，可能同时受到代理、网络、防火墙和上游服务影响。

第 6 步：用 Git 详细日志确认它到底走了哪里

当配置看起来都正常但 Git 仍失败，可以临时打开 Git 的调试输出。Git 官方文档说明，GIT_TRACE 可输出一般跟踪信息，GIT_TRACE_CURL 可输出 Git 传输过程中的 curl 追踪信息。

1. 在 PowerShell 中运行 $env:GIT_TRACE="1"; $env:GIT_TRACE_CURL="1"; git ls-remote https://github.com/用户/仓库.git。
2. 查看输出中是否出现代理地址、连接目标、证书错误、407、超时或连接拒绝。
3. 排查结束后关闭临时变量：Remove-Item Env:GIT_TRACE -ErrorAction SilentlyContinue; Remove-Item Env:GIT_TRACE_CURL -ErrorAction SilentlyContinue。
4. 分享日志前先检查是否包含用户名、代理地址、令牌、Cookie 或其他凭据。Git 文档说明部分敏感请求头默认会被脱敏，但仍应人工复核。

如果日志显示 Git 连接的是旧代理地址，说明 Git 配置或环境变量仍在生效；如果日志显示已经连接到正确代理但在 TLS 阶段失败，应转向证书、系统时间、SSL 检查或代理透明性排查。

Git 官方文档还特别指出，代理应尽量保持透明，不应修改、转换或缓存 Git 请求与响应，否则可能造成 Git 传输异常。

第 7 步：DNS、防火墙、IPv6 与企业网络的最后检查

1. 检查 DNS。运行 nslookup github.com、nslookup api.github.com 和 nslookup raw.githubusercontent.com，记录是否都能返回地址。若只有某个域名失败，先不要修改 hosts 文件，先确认是否为 DNS 或网络策略问题。
2. 检查防火墙和安全软件。如果错误只发生在 Git、GitHub Desktop 或某个命令行程序，确认该程序是否被 Windows 防火墙或安全软件拦截。不要为了测试长期关闭防护；如必须临时验证，应立即恢复原设置。
3. 比较 IPv4 与 IPv6。如果某个网络环境下连接反复超时，而换网络后正常，可能存在 IPv6 路径或网络出口差异。先以日志和重复测试为依据，不要在没有证据时直接禁用 IPv6。
4. 确认企业网络限制。公司、学校或公共网络可能要求使用指定代理、认证或放行规则。GitHub 建议遇到组织网络阻断时联系网络管理员确认规则，而不是擅自绕过网络安全策略。

如果以上步骤仍无法定位，可以使用 GitHub 提供的连接诊断工具或向网络管理员提供脱敏后的错误日志、测试时间、网络环境和目标地址。

适合收藏的 Windows GitHub 代理排查清单

• 代理端：客户端运行，HTTP 或混合端口正确，本机端口测试成功。
• 目标端：分别验证 github.com、api.github.com、raw.githubusercontent.com 和实际 Git HTTPS 请求。
• 系统端：检查 Windows 系统代理、netsh winhttp show proxy 和环境变量。
• Git 端：检查全局与仓库级 http.proxy，清理失效配置后重新测试。
• 错误端：按照 407、502、超时、连接拒绝和 SSL 错误分流，不要用关闭 SSL 校验代替证书修复。
• 验证端：以 Git 实际返回引用、页面实际加载和重复测试结果作为成功标准，不能只看开关状态。

如果你只需要下载公开文件或仓库，也可以先阅读本站的GitHub 文件下载方法；如果问题表现为所有软件都连接超时，可继续查看代理连接超时排查步骤。

总结

Windows 代理设置后 GitHub 打不开，最常见的误区是把“浏览器代理已开启”当成“所有应用都会自动走代理”。正确顺序是先确认本地代理端口，再分别测试浏览器、命令行和 Git，随后检查 WinHTTP、环境变量、Git 独立配置、DNS、防火墙和证书。

如果只想快速恢复 Git，优先执行配置来源检查和旧代理清理；如果所有应用都失败，优先修复代理端口或网络链路；如果出现证书错误，优先建立可信证书链，不要永久关闭 SSL 校验。

常见问题

为什么 Windows 浏览器能打开 GitHub，但 git clone 仍然失败？

浏览器和 Git 可能使用不同代理配置。Git 可以通过 http.proxy、https.proxy、环境变量或仓库级配置单独指定代理，因此应先运行 git config --show-origin --get-regexp "proxy|ssl"，再检查 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。

Windows 的系统代理和 WinHTTP 代理是同一个东西吗？

不是完全相同。部分应用读取用户级系统代理，另一些应用或服务使用 WinHTTP。可以运行 netsh winhttp show proxy 查看 WinHTTP 配置；确认配置过期且当前网络不需要时，可运行 netsh winhttp reset proxy 恢复直连。

GitHub 报 407 代理认证失败怎么办？

407 通常表示代理要求认证，但凭据或认证方式没有通过。先确认用户名、密码、代理地址和端口，再检查 Git 的 http.proxy 配置。不要把长期密码直接写进仓库地址、脚本或公开日志中。

出现 SSL certificate problem，能不能直接关闭 Git 的 SSL 校验？

不建议把关闭校验作为长期解决方案。应先检查系统时间、证书链、企业 SSL 检查和代理证书，并通过可信根证书修复验证链。Git 的 http.sslVerify 默认用于验证 HTTPS 证书，临时关闭会降低连接安全性。

如何确认 Git 真的使用了代理？

可以临时设置 GIT_TRACE=1 和 GIT_TRACE_CURL=1，再执行 git ls-remote。查看日志中的代理地址、目标主机、认证状态和 TLS 阶段；分享日志前应删除令牌、用户名、密码和其他敏感信息。

相关阅读

• 代理连接超时怎么排查
• 代理报错代码对照
• 浏览器能用但软件不能用
• GitHub 文件下载方法

参考资料

1. GitHub Docs：Troubleshooting connectivity problems
2. GitHub Docs：Using proxy servers with a runner
3. Git 官方文档：git-config（git-scm.com）
4. Git 官方文档：git（git-scm.com）
5. Microsoft Learn：netsh winhttp