bash
Post "https://oauth2.googleapis.com/token": dial tcp 198.18.0.17:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
报错速判表
| 报错特征 | 含义 |
|---|---|
dial tcp 198.18.x.x |
代li 虚拟 IP（fake-ip 池），代li处于半死状态 |
dial tcp 127.0.0.1 |
本地服务没起 |
connectex 超时 / No response |
目标端口没有进程在监听 |
| 返回了 HTTP 4xx | 其实是通的------请求已到达对方服务器，别误判成网络故障 |
一步排查
bash
# 1. DNS：系统 DNS 是否被代li改成 127.0.0.1 且无人应答？
nslookup www.baidu.com
# → "服务器: 127.0.0.1，No response" = DNS 已被接管但代li DNS 没工作
# 2. 出站：代li本身能不能出网？用对照组
curl -sI --connect-timeout 8 https://www.baidu.com -o /dev/null -w "%{http_code}\n" # 直连：验本机网络
curl -sI --connect-timeout 8 -x http://127.0.0.1:7890 https://www.baidu.com ... # 走代li普通站：验代li出站
curl -sI --connect-timeout 8 -x http://127.0.0.1:7890 https://目标服务 ... # 走代li目标站：验最终链路对照组判读（本案例的关键一步）：
- 直连普通站 ✅ + 走代li普通站 ❌ → 问题在代li本身（出站失效/上游不可用），别再盯着目标服务
- 直连普通站 ❌ → 本机网络问题，和代li无关
- 走代li普通站 ✅ + 走代li目标站 ❌ → 上游或分流规则问题
修复组合拳
ipconfig /flushdns------清掉 DNS 缓存里残留的假 IP（198.18.x.x）- 完全重启出问题的应用------它进程内缓存着假 IP 和旧网络配置，很多应用只在启动时读取代li设置
三个最容易踩的坑
- 假 IP 残留：代li挂掉后，DNS 缓存和应用进程内还留着 198.18.x.x，不刷缓存/不重启应用就一直撞墙
- 系统 DNS 残留：代li曾把系统 DNS 设成 127.0.0.1，代li停了这条设置还在，全机域名解析跟着遭殃
- 只重启代li 没用：应用侧的配置同样要重启刷新，两端都要"重来一遍"
方法论三条
- 先读报错里的 IP，它直接指向故障层：198.18.x.x→代li，127.0.0.1→本地服务，公网 IP→可达性
- 进程在 ≠ 服务在 ：一切以
netstat看到LISTENING为准，再用 curl 实测连通 - 验证贴近真实场景：故障是 POST 就用 POST 测，只 ping 通不算数