httpx 的 -proxy 参数不支持直接传入带认证的代理 URL，因其底层 fasthttp 不解析 URL 中的用户密码字段；需用 -http-proxy-header 手动注入 Base64 编码的 Proxy-Authorization 头，格式为“Basic base64(username:password)”。
httpx 的 -proxy 参数不支持直接传入带认证的代理 URL
很多人尝试用 httpx -proxy http://user:pass@host:port 发现认证失败，甚至返回 407 Proxy Authentication Required。这是因为 httpx（截至 v1.6.x）底层使用 fasthttp，而 fasthttp 默认**不解析 URL 中的用户密码字段**来设置 Proxy-Authorization 头——它只提取 host/port 建立连接，认证需手动注入。
正确方式：用 -http-proxy-header 手动添加 Proxy-Authorization 头
必须将 Base64 编码后的 username:password 通过 -http-proxy-header 注入，且注意格式和编码细节：
- 编码前字符串必须是
username:password（不含协议、无空格、无额外斜杠） - 使用标准 Base64（非 URL-safe），例如
echo -n "admin:123" | base64→YWRtaW46MTIz - Header 值格式为
Basic YWRtaW46MTIz（注意Basic后有一个空格） - 完整命令示例：
httpx -u https://example.com -proxy http://127.0.0.1:8080 -http-proxy-header "Proxy-Authorization: Basic YWRtaW46MTIz"
常见错误与绕过限制的替代方案
如果手动编码出错或代理要求 Digest 认证（httpx 当前完全不支持），会出现连接挂起、超时或 407 持续返回。此时可考虑：
- 换用支持完整代理认证的工具，如
curl -x user:pass@host:port或gau | httpx -http-proxy-header ...配合外部代理链 - 在本地启动一个无认证的中间代理（如
mitmproxy --mode upstream:http://user:pass@real-proxy:port），再让httpx连这个中间代理 - 确认代理服务是否强制校验
Proxy-Connection或User-Agent头，必要时用-H补充
注意 fasthttp 的底层限制会影响所有基于它的工具
不只是 httpx，naabu、katana 等同样基于 fasthttp 的项目都继承这一行为。如果你写 Go 脚本调用 fasthttp.ProxyClient，也得自己构造 Proxy-Authorization 并设到 Request.Header.Set()，不能依赖 WithProxyURL() 自动解析。
