某些网站（如 whatismyipaddress.com）会检测并拦截缺乏标准浏览器特征的请求，导致仅返回调试头信息而非真实页面内容；根本原因在于缺失合法 user-agent 等关键请求头，需显式构造模拟真实浏览器的 headers。
某些网站（如 whatismyipaddress.com）会检测并拦截缺乏标准浏览器特征的请求，导致仅返回调试头信息而非真实页面内容；根本原因在于缺失合法 user-agent 等关键请求头，需显式构造模拟真实浏览器的 headers。
在使用 requests 库配合代理（proxy）发起 HTTP 请求时，看似相同的代码对不同目标站点可能产生截然不同的响应——例如成功获取 Google 首页 HTML，却对 whatismyipaddress.com 仅返回一串环境变量式的响应头（如 REMOTE_ADDR、HTTP_USER-AGENT 等）。这并非代理失效或 requests bug，而是目标服务器主动识别并拒绝了“非浏览器类”请求。
本质原因是：whatismyipaddress.com 等站点部署了反爬/反自动化访问策略，当检测到请求中缺少符合常规浏览器行为的 User-Agent、Accept、Accept-Language 等关键 header 时，会跳过正常页面渲染逻辑，转而返回一个诊断性响应（常用于调试代理链路），即你看到的纯头信息输出。
✅ 正确做法是显式构造具备真实浏览器特征的请求头。以下为修复后的完整示例：
import requests
proxies = {
'http': 'http://3.127.121.101:80',
'https': 'http://3.127.121.101:80' # 注意：协议前缀应统一为 'http://'，requests 会自动适配 HTTPS 流量
}
headers = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8',
'Accept-Language': 'en-US,en;q=0.9',
'Accept-Encoding': 'gzip, deflate',
'Connection': 'keep-alive',
'Upgrade-Insecure-Requests': '1',
}
try:
response = requests.get(
"https://whatismyipaddress.com/",
proxies=proxies,
headers=headers,
verify=False, # ⚠️ 生产环境请勿禁用 SSL 验证；建议使用 requests.packages.urllib3.disable_warnings() + 自定义 CA 证书
timeout=15
)
response.raise_for_status() # 检查 HTTP 错误状态码
print("Status Code:", response.status_code)
print("Content Length:", len(response.text))
print("First 200 chars:", response.text[:200])
except requests.exceptions.RequestException as e:
print("Request failed:", e)
? 关键注意事项：
-
Proxy 字典键名必须准确：应为
'http'和'https'（不含://），原问题中'http://'是无效键，会导致代理未生效； -
User-Agent 需保持时效性：避免长期复用过时 UA（如 Chrome 91），建议定期更新为当前主流版本，或使用
fake-useragent动态生成； - HTTPS 代理兼容性：部分 HTTP 代理不支持 CONNECT 隧道，无法代理 HTTPS 请求；若仍失败，可尝试将目标 URL 改为 HTTP（如可用）或更换支持 HTTPS 的 SOCKS5 代理；
-
SSL 验证安全警示：
verify=False会跳过证书校验，存在中间人攻击风险，仅限测试；生产环境务必启用证书验证，并配置可信 CA 或指定cert=参数； -
补充防御性头字段：除
User-Agent外，添加Accept-Encoding: gzip可提升响应速度；Upgrade-Insecure-Requests和Sec-Fetch-*类头（如需更高拟真度）可进一步降低被识别概率。
总结：该现象是典型的服务端 UA 检测机制触发的结果。解决核心在于——让请求“看起来像浏览器”。通过规范代理配置、注入完整且合理的请求头，并辅以超时与异常处理，即可稳定获取目标网页的真实 HTML 内容。
