坑所属项目 ↗2026-10-03

智能体 shell 注入 http_proxy，连通性探测出全 200 假阳性

在智能体环境里用 curl 探测 GitHub 各 IP 连通性，四个 IP 全部返回 200，看似全通；核验 %{remote_ip} 才发现连的全是 127.0.0.1（本机代理），--resolve 被完全忽略，四条都是假阳性。解法：加 --noproxy '*' 绕过代理，并强制输出 remote_ip 与目标 IP 比对，不相等即判无效。

  • curl
  • 代理
  • 假阳性
  • 网络
  • 验收

现象

  • 执行连通性探测 curl.exe --resolve github.com:443:<ip> https://github.com，4 个候选 IP 全部返回 200
  • “全部都通”不符合常理（真实直连应有明显的耗时分层），触发复核

根因

  1. 执行环境（智能体沙箱 shell）预置了 http_proxy / https_proxy，指向本机代理 127.0.0.1
  2. curl 走代理时，DNS 解析和建连都由代理完成，--resolve 指定的 IP 映射被静默忽略
  3. -w %{remote_ip} 显示连接的是 127.0.0.1 而非目标 IP——探测的实际是代理，代理本身能通 GitHub，所以四个”IP”全绿

解法（已验证）

  1. 探测命令加 --noproxy '*'，强制直连
  2. 输出必须带 %{remote_ip}，且与 --resolve 的目标 IP 比对，不一致直接判该次探测无效
  3. 复测真实结果——4 个 IP 直连全部 200，但耗时分层明显（TLS 0.54s1.57s，总耗时 0.81s2.94s），这才是可用于决策的数据

延伸：同一个坑在 git 上的表现与解法

同一台机器上 git 也会走 shell 注入的代理（CONNECT tunnel failed, response 502 / schannel: server closed abruptly，间歇性，3 次里只成功 1 次），而且代理模式下 http.curloptResolve 会被忽略——即使指定了直连 IP，流量仍然过代理。已验证的解法是把两件事一起配进仓库：

git config --local http.proxy ""                                        # 强制不走代理，覆盖 http_proxy 环境变量
git config --local http.curloptResolve "github.com:443:140.82.114.3"    # 直连指定 IP

效果：git fetch 在无代理环境 3/3 成功；配了 http.proxy "" 后，即使 shell 里仍有 http_proxy，也是 3/3 成功。 撤销：git config --local --unset http.proxy / --unset http.curloptResolve。

验证

  • 修正后 remote_ip 与目标 IP 一致
  • 依据真实耗时数据选定 140.82.114.3（最快 0.81s）作为候选，替代原 hosts 里较慢的 140.82.113.4（2.20s）
← 返回全部归档