Connection error — 四种完全不同的失败，共用同一个名字

1 · 第 1 级 — 名字解析得出来吗？#

HOST=$(echo "https://api.9coding.com" | awk -F/ '{print $3}' | cut -d: -f1)
echo "$HOST"
getent hosts "$HOST" || nslookup "$HOST"

• 回得出地址 → 第 1 级通过。把地址记下来，第 2 步要用。
• ENOTFOUND / NXDOMAIN → 要么主机名写错了，要么你的解析服务器答不出这个名字。

要分开这两种，把同一个问题丢给另一个解析服务器：

nslookup "$HOST" <another-resolver-ip>

• 换一个解析服务器就查得到，用默认的查不到 → 问题在你的 DNS，不在端点。常见原因是 VPN、容器里的解析配置，或一条过期的 /etc/hosts。

grep -i "$HOST" /etc/hosts

• 换哪个解析服务器都查不到 → 一个字一个字核对主机名。到处都解析不出来的名字，几乎都是打错，或者把只在内网有效的名字拿到外面用。

2 · 第 2 级 — 端口到底开没开？#

用 --resolve 自己把地址钉死，等于把 DNS 完全排除在这个实验之外，这样这里失败就只可能是 TCP。

curl -sS -v --connect-timeout 5 --resolve "$HOST:443:203.0.113.10" \
  -o /dev/null "https://$HOST/" 2>&1 | grep -E 'Trying|Connected|refused|timed out'

把 203.0.113.10 换成第 1 步打印出来的地址。

• Connected to ... → 第 2 级通过，去第 3 步。
• Connection refused（ECONNREFUSED） → 有人回答了，答案是「不」。那个端口上没有东西在监听。
• Connection timed out（ETIMEDOUT） → 根本没人回答。包被丢掉了：防火墙、网络策略，或一条哪儿都到不了的路由。

做任何事之前，先看报错里的那个地址。如果 ECONNREFUSED 后面写的是 127.0.0.1 或 localhost——就像本页最上面第二段报错那样——那你的请求根本没送到端点。是某个代理环境变量把客户端指向了本机的一个端口，而原本在那儿监听的东西没在跑。光这一个细节，就能解掉相当一部分「它坏了但我什么都没动」的案例，而你把端点查到天亮也查不出这件事。

Refused 和 timed out 的意思是相反的，这点值得说白：refused 是快速而明确的拒绝，timed out 是沉默。关着的端口会立刻回答你，防火墙什么都不说。

3 · 第 3 级 — TLS 握手完成得了吗？#

openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>&1 | head -25

• Verify return code: 0 (ok) → 第 3 级通过，去第 4 步。
• unable to get local issuer certificate / self-signed certificate in certificate chain → 第 3 级失败在「信任」，不是失败在「连不连得上」。连接建立成功了、然后证书校验没过，这和「根本没走到那一步」是两个不同的问题。请看 TLS 证书错误，别再继续查网络。
• 证书签发给一个你不认识的名字 → 你和端点之间有东西把 TLS 拦下来重新签了。那是中间拦检设备，也是同一页。

有一个特性值得记住，因为它能让你直接跳过这一级：TLS 失败是必然的。同一个客户端、同一份信任库、同一张证书，第一次会失败，之后每一次都会失败。所以只要你的失败是时好时坏的，问题就不在第 3 级。

4 · 第 4 级 — 服务器有回应吗，以及到底断在哪一级？#

只要会读，这一条命令抵得上整把梯子。curl 会报出每一级完成的时间点，没完成的那一级会报 0.000000。

# <模型 id>：从 https://api.9coding.com/v1/models 里复制一个
curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} status=%{http_code}\n' \
  https://api.9coding.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"<模型 id>","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

把输出留着。dns=1.9 或 tcp=4.8 不算失败，但是个警告：某个环节慢到一定程度时，超时设置比 curl 短的客户端就会报 Connection error，而 curl 这边是成功的。

5 · 梯子上没有的那一级 — 客户端走的路，可能和 curl 不一样#

这种情况最让人怀疑自己的眼睛：同一台机器、同一秒，curl 通了，客户端不通。

常见的解释是代理环境变量。curl 会读 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY。别的客户端可能会读，可能只读小写那组，可能要求你另外配置，也可能完全不理——于是 curl 和客户端会走在两条不同的网络路径上。

env | grep -i -E 'proxy'

然后把第 4 级跑两次——一次照原样，一次把代理变量拔掉——再比对：

# <模型 id>：从 https://api.9coding.com/v1/models 里复制一个
env -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy -u ALL_PROXY -u all_proxy \
  curl -sS -o /dev/null -w 'status=%{http_code}\n' https://api.9coding.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"<模型 id>","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

还有两件事值得知道：

• 三个变量里最常设错的是 NO_PROXY。前导点、端口、通配符的匹配规则在各家实现之间并不一致，所以一个对某个工具有效的写法，可能被另一个工具默默忽略。排除规则要实测，不要假设——而且要在你自己正在跑的那个客户端版本上实测。
• 如果代理变量指向 127.0.0.1，那这台机器上所有读它的程序，都依赖某个本机进程一直活着。那个进程一停，所有读这个变量的客户端会同时报 ECONNREFUSED，而所有不读它的客户端照样能用。这种不对称，看起来非常像「只有某一个 App 坏了」。