问题场景回顾 #

你用Wget生成多域名站点地图时执行了以下命令：

wget --spider --recursive --level=2 --no-verbose --follow-tags=a --wait=0.5 "http://example.com" -e use_proxy=yes -e http_proxy=http://user:pass@1.2.3.4:3128

批量处理100个域名时，90%正常，但10%出现畸形URL重定向：本该请求http://example.com/index.html，却变成了http://example.comhttp/example.com/index.html，且仅在使用3proxy代理时触发，排除Wget本身的Bug。

核心原因分析（聚焦3proxy的逻辑缺陷） #

这个问题的本质是3proxy在处理HTTP请求或重定向响应时，出现了URL拼接/解析的错误，具体可能有以下几种情况：

• 重定向Location头解析逻辑漏洞
  当目标站点返回相对路径的Location头（比如Location: /index.html或Location: index.html）时，3proxy没有正确将其与原请求的域名拼接。比如它可能漏掉了://分隔符，或者错误重复拼接了原域名，导致生成example.comhttp/example.com/index.html这种畸形URL，最终被Wget补全成错误的请求地址。

• HTTP请求行转发错误
  正常情况下，客户端（Wget）向代理发送的请求行是GET /index.html HTTP/1.1，代理需要将其转换为GET http://example.com/index.html HTTP/1.1转发给目标服务器。如果3proxy在这个转换过程中出现逻辑错误（比如重复添加域名），后续处理重定向时就会叠加错误的URL片段。

• 特定域名的HTTP头兼容性问题
  你提到的几个异常域名（如http://leylandslearningcentre.com.au）可能返回的Location头格式比较特殊（比如缺少开头的/，或者包含非标准的相对路径写法），而3proxy的解析逻辑没有覆盖这种边缘场景，导致拼接失败。

• 旧版本3proxy的Bug
  较早期的3proxy版本存在HTTP请求/响应处理的已知Bug，比如在处理Host头或重定向URL时的逻辑错误。如果你的3proxy版本不是最新稳定版，这个问题很可能是版本Bug导致的。

验证与排查建议 #

1. 抓包对比分析：用tcpdump或Wireshark抓取3proxy与目标站点之间的流量，对比正常域名和异常域名的请求/响应，查看Location头和请求行的格式差异。
2. 开启3proxy debug日志：配置3proxy开启详细的debug日志，查看异常请求的处理过程，定位URL拼接错误的具体环节。
3. 升级3proxy版本：尝试升级到最新的稳定版3proxy，看是否能解决这个边缘场景的兼容问题。
4. 单一域名测试：用出现问题的域名单独执行Wget命令，结合代理日志，更精准地定位触发条件。

内容的提问来源于stack exchange，提问作者qlwik