Ping 正常，curl 却失败：一次 NAS 网络故障与代理变量

语言： English | 简体中文

发布日期：2026-01-09

一次普通维护遇到了并不普通的网络问题。最后，根因来自我以前留下的配置。

背景碎碎念

我的旧笔记本运行 Arch Linux，承载 Jellyfin、Paperless-ngx、机器人等 Docker 服务，以及 Samba。学业占用了不少时间，但我还是想把这些实际排错过程记录下来，也让未来雇主了解我如何处理系统问题。

现象与结论

• ping 8.8.8.8 正常。
• curl https://www.google.com 超时。
• curl -v 显示请求使用 all_proxy=socks://127.0.0.1:8889。
• 本地代理已停止，HTTP 请求仍被送往这个地址。
• 当前 shell 取消代理变量，并从启动配置移除旧 export 后恢复。

为什么现象容易误导

路由看起来合理，ICMP 能通，所以我最初认为网络没有问题。但应用请求走的路径与 ping 不同。外部 HTTPS 和部分继承代理配置的客户端同时失效，并不能仅靠 ping 排除应用层问题。

ICMP 与 HTTP 的区别

ICMP 是 Internet Control Message Protocol，常见于 ping 和网络诊断，例如确认节点响应、报告目标不可达或数据包过大。

ping 使用 ICMP；这里的 curl 请求使用 HTTP/HTTPS 和 TCP。代理、环境变量与应用配置可能影响 curl，而完全不影响 ping。因此 ICMP 成功只能证明对应诊断路径可达。

起初检查了什么

我先用 ip route、ip rule 检查默认路由和 Tailscale / VPN 策略；通过 /etc/resolv.conf、dig google.com 或 nslookup 核对 DNS；也临时排查了 overlay 路由干扰。这些都没有解释 HTTP 失败。

真正的线索：curl -v

Verbose 输出包含：

Uses proxy env variable all_proxy == 'socks://127.0.0.1:8889'

问题因此从“网络为什么坏了”，变成“curl 为什么没有直接访问网络”。我曾设置这个 SOCKS 代理，但对应服务已经不运行。

Ping 不读取 HTTP 代理，照常成功；curl 读取环境变量，连接没有 listener 的 127.0.0.1:8889，因而失败。继承同类配置的容器或 HTTP 客户端也可能受到影响。

修复

当前 shell 中清理曾设置的代理变量：

unset all_proxy http_proxy https_proxy

然后检查 ~/.bashrc、~/.zshrc 等启动文件，移除已过期的 export all_proxy=...、http_proxy 或 https_proxy。重新启动 shell 或登录后，再用 curl 验证。

这次排错留下的经验

• Ping 成功不等于应用连接成功。
• HTTP 异常时尽早查看 curl -v。
• 环境变量会影响多个程序，应与路由、DNS、容器网络一起排查。
• 服务停止后，旧客户端配置仍可能持续生效。

以后我希望把 DNS、路由、MTU、代理变量和 Docker 网络整理为一份维护清单，也继续记录容器化项目的实际问题。