connection timed out这个报错几乎每个开发者都遇到过：明明浏览器能上网，命令行里git clone却卡死；或者刚关掉VPN，所有网络请求瞬间全部超时。这类问题看似玄学，其实背后大多是代理设置残留和域名解析异常在作怪。本文围绕代理设置与Hosts文件修改这两个最常见的排查方向，把原理、操作和验证方法一次性讲清楚。
一、先搞清楚超时的两种典型成因
网络连接超时的本质是客户端在规定时间内没有收到目标服务器的响应。造成这个现象的原因很多，但在开发环境里，代理配置残留和DNS解析失败是占比最高的两类。
代理问题通常表现为：之前为了加速访问配置了HTTP代理或者开启了VPN工具，后来工具关了或者切换了模式，但系统或环境变量层面的代理地址还留着。此时请求会被发往一个已经不存在的代理端口，比如常见的127.0.0.1:7890，这个端口没人监听，请求自然就超时了。这种情况有个明显特征：浏览器可能正常（走的是另一套代理规则），而curl、git、pip等命令行工具全部超时。
DNS问题则相反：代理通路是好的，但域名解析出来的IP不对，或者干脆解析不出来。比如某些域名在本地网络环境下解析到的IP不可达，请求发出去石沉大海。这时候修改Hosts文件，把域名手动指向一个可达的IP，往往能立刻见效。
二、代理设置的排查与清理
1. 检查环境变量
命令行工具大多会读取http_proxy和https_proxy这两个环境变量。排查第一步就是看看它们是否存在：
# 查看当前代理相关环境变量 env | grep -i proxy # 临时清除当前会话的代理变量 unset http_proxy unset https_proxy unset all_proxy
如果输出里有代理地址，而对应的代理工具并没有在运行，那就是超时的元凶。临时清除用unset即可，永久清除需要检查shell配置文件。Mac和Linux用户看~/.bashrc或~/.zshrc里有没有export proxy相关的行，Windows用户则要检查系统环境变量设置。
2. 区分系统代理和Git单独配置
很多人忽略了git有自己独立的代理配置。即使环境变量清干净了，gitconfig里写死的代理依然会生效。查看和清理方法如下：
# 查看git的全局配置中是否设置了代理 git config --global --get http.proxy git config --global --get https.proxy # 取消git的代理设置 git config --global --unset http.proxy git config --global --unset https.proxy
反过来，如果确实需要让git走代理（比如公司内网必须通过代理访问外网），则可以用下面的命令显式指定，注意socks5和http协议的写法区别：
# 设置http协议代理 git config --global http.proxy http://127.0.0.1:7890 # 设置socks5代理 git config --global http.proxy socks5://127.0.0.1:7890 # 只对特定域名启用代理 git config --global http.https://github.com.proxy http://127.0.0.1:7890
最后一条按域名配置代理的写法非常实用，可以做到访问公司内部仓库直连、访问外部仓库走代理，互不干扰。
3. Windows系统代理的检查
Windows下很多代理工具（如Clash等）会自动修改系统代理。在设置的网络和Internet选项里可以看到代理开关状态。一个常见的坑是：工具异常退出时没有恢复系统代理，导致代理地址指向一个已关闭的本地端口。用PowerShell可以快速验证：
# 查看当前系统代理设置 Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer
如果ProxyEnable为1而ProxyServer指向的端口没有进程监听，直接在设置里关闭使用代理服务器选项即可恢复。
三、Hosts文件修改的原理与操作
1. Hosts文件为什么能解决问题
操作系统在解析域名时，优先级最高的就是本地的Hosts文件，其次才会去询问DNS服务器。也就是说，把某个域名写进Hosts，等于绕过了DNS解析，直接指定它对应的IP。当DNS解析被污染、或者运营商解析结果不可达时，手动指定一个正确的IP就能让连接恢复。这个方法常用于加速访问某些代码托管平台，或者在内网环境中把域名指向内部服务器。
2. 各平台Hosts文件位置与修改方法
三个主流平台的Hosts文件路径如下：Windows是C:\Windows\System32\drivers\etc\hosts，Mac和Linux是/etc/hosts。注意Windows路径必须用反斜杠，别写成斜杠。
修改格式很简单，一行一条记录，前面是IP地址，后面是域名，中间用空格或Tab分隔：
140.82.114.4 github.com 199.232.69.194 github.global.ssl.fastly.net
Windows修改时需要注意权限问题：hosts文件默认需要管理员权限，建议用管理员身份打开记事本再编辑，直接双击打开修改后保存会提示拒绝访问。Mac和Linux下用sudo配合vim或者nano编辑即可：
sudo vim /etc/hosts # 编辑完成后刷新DNS缓存（Mac） sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
3. 修改后的验证方法
改完Hosts不等于生效，还要验证解析结果。最直接的方式是用ping看解析出来的IP是否是你写入的地址：
ping github.com # 或者用nslookup对比，注意nslookup默认不走hosts，查询的是DNS服务器 nslookup github.com
这里有个容易迷惑的点：nslookup和dig查询的是DNS服务器，不读取本地Hosts文件，所以Hosts改对了但nslookup结果没变是正常的。判断Hosts是否生效，用ping或者直接curl目标地址更准确。
四、常见坑与综合排查建议
第一，代理工具的TUN模式会接管全部流量，这时候清环境变量、改Hosts都没用，必须回到工具里关闭TUN模式或者调整分流规则。
第二，Hosts里写入的IP本身也可能失效。IP地址不是永久不变的，如果写入一个过期IP，反而会把原本能解析的域名指向错误地址，导致新的超时。可以通过一些在线的IP检测服务获取目标域名当前可用的IP再写入。
第三，浏览器有自己的DNS缓存和安全DNS功能，改完Hosts后浏览器可能还在用旧结果。Chrome地址栏输入chrome://net-internals/#dns可以清除浏览器DNS缓存，或者直接无痕模式测试。
综合排查时建议按这个顺序来：先用curl直连IP测试网络通不通，再排查代理变量和git配置，最后才动Hosts。分层定位比一上来就乱改配置效率高得多。多数情况下，超时问题在第二步清理代理时就已经解决了。
五、总结
连接超时问题虽然表现五花八门，但核心排查路径就两条：代理链路是否干净、域名解析是否正确。代理排查重点在环境变量、git独立配置和系统代理三层；Hosts修改则是解决DNS层面问题的利器，改完记得用ping验证并清理DNS缓存。把这两套方法练熟，以后再遇到connection timed out，几分钟内就能定位到问题根源，不再靠重启碰运气。