先把当时的情况摆出来。CentOS 7.9 上 node_exporter 1.6 由 systemd 拉起，ss -lntp 显示 9100 在听，Prometheus 上该 target 报 Get http://10.0.0.11:9100/metrics: proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused。
把日志和配置对完，能解释这个现象的基本就这几处。机器为 yum 和 curl 配了 http_proxy 并写进 /etc/environment，Prometheus 进程直接继承。另一种情况是unit 文件里 Environment= 又带了一份 HTTP_PROXY，restart 后一直生效。
还有一种情况，no_proxy 只写了 localhost，没写 127.0.0.1 和内网段，抓取仍然走代理。
手工复现抓取请求
curl -v http://127.0.0.1:9100/metrics 2>&1 | head -5再往下绕过代理再测一次
curl --noproxy '*' -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9100/metrics给服务清掉代理变量
systemctl set-environment no_proxy=localhost,127.0.0.1,10.0.0.0/8末了重启并确认进程环境
systemctl restart prometheus; tr '\0' '\n' < /proc/$(pgrep prometheus)/environ | grep -i proxy当时还开着另一个排查窗口，两边日志对照着看才定位到。
同一份数据我导出了两份，一份留底，一份拿来试。
这类问题以前遇到过，但这次的触发条件和上次不一样。
这类改动我都写进变更记录，过两周再出问题时能对上号。
别只看报错消失，验证要多做一步。Prometheus 的 targets 页面该 job 从 DOWN 变 UP，Last scrape 在 15 秒内持续刷新，curl 的 http_code 返回 200。
提醒一点。代理变量对 scrape 的影响很隐蔽，报错里出现 proxyconnect 就不用再查 exporter；内网抓取一律显式配 no_proxy。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。