进小区要刷门禁卡，进代理IP服务同样要亮凭证。HTTP 代理IP要求认证时，凭证不是单独输入的，而是藏在一个叫 Proxy-Authorization 的请求头里，随每次请求一起送过去。
先说结论：Proxy-Authorization 头是专门写给代理看的认证头。代理要求认证时会先回一个 407 状态码，客户端收到后把凭据放进这个头再重新请求，通过之后才开始正常转发。
这个头和给目标站用的 Authorization 头长得很像，但对象完全不同，混用是认证失败最常见的原因之一。
认证报文是怎么拼出来的
最常见的是 Basic 认证方式。客户端把「用户名:密码」拼成一个字符串，用 Base64 编码，再按「Basic 编码结果」的格式填进 Proxy-Authorization 头。整个过程不需要加密，只是编码，所以凭据其实是可还原的。
正因为可还原，Basic 认证只适合在可信链路上使用。走 HTTP 明文时，凭据经过的每一跳都能读到；这也是为什么正规代理IP服务会配合 HTTPS 或白名单等方式加强防护，而不是只靠这一个认证头。
编码不等于加密，这一点要分清。
407 和这个头是怎么配合的
流程是先问后给：客户端第一次请求没带认证头，代理回 407 并附带它支持的认证方式；客户端按指定方式拼好 Proxy-Authorization 头，重新发起请求；代理验证通过后放行，之后每次请求都带上这个头。
- 发起请求时不带凭据
- 代理回 407，说明要认证并给出支持的认证方式
- 客户端按指定方式拼好 Proxy-Authorization 头
- 带上认证头重新发起请求
- 代理验证通过，正常转发业务请求
从抓包角度看，一次成功的认证会看到两次请求：第一次被 407 挡回来，第二次带着认证头通过。如果只看到第一次没有第二次，说明客户端没有正确处理 407 的提示。
它和 Authorization 头有什么不同
两者长相相似，对象不同。Authorization 是写给目标站的，Proxy-Authorization 是写给代理的。走多级代理时，每一级代理都可能要自己的认证，各自的认证头只对自己的那一段生效。
看到请求里有 Authorization 而不见 Proxy-Authorization，说明认证是目标站要的；两个头都在，说明代理和目标站各自都要凭据。分清对象，排查认证失败就快很多。
还有一种常见情况：代理要求认证但客户端软件不支持设置代理账号，导致请求一直被 407 挡着。这时换一个支持代理认证的客户端，或者在代理IP服务端配置白名单，都能绕开这个瓶颈。
认证头是代理IP服务的第一道门：407 要，客户端给，验证过才放行，过程里每一步都有明确的协议语义。
为什么代理IP的认证头要随请求一起走，而不是登录一次就完事？因为 HTTP 是无状态的，代理IP无法记住上一次请求是谁，只能靠每次请求携带的认证头来验证身份。这是协议设计使然，理解了这一点，就不会再奇怪为什么每次请求都要带凭据了。