代理身份验证：身份验证方法、设置与最佳实践完整指南

代理认证控制着谁可以访问代理服务器以及客户端如何证明自己的身份。大多数代理提供商支持用户名/密码认证、IP 白名单，或两者兼有。了解这些方法的工作原理有助于你正确配置代理、排查诸如 HTTP 407 之类的连接错误，并为你的工作流程选择最佳设置。

这一点在 2026 年比几年前更为重要。代理网络规模更大，IP 轮换更快，而且大多数认真的抓取或 自动化工作流程 如今都在大规模地通过某种形式的认证代理运行。无论您是用 Python 连接请求的开发者、配置 Selenium 的 QA 工程师，还是管理数千个会话的运维团队，您都需要准确了解代理认证的工作原理。

本指南涵盖当今使用的每一种认证方法、如何在你实际使用的各类工具中实现每一种方法、如何为你的使用场景选择合适的方法，以及如何修复最常出现的错误。

几分钟内即可配置带身份验证的住宅代理、ISP 代理和移动代理。使用 NodeMaven 起价 3.50 美元即可开始,并附赠 750 MB 流量

开始试用

什么是代理认证？

代理认证是指代理服务器在将流量转发到目标服务器之前，用于验证客户端身份并授权访问的过程。

这个定义中包含两个不同的概念：

• 身份验证 确认谁在连接

这通常通过代理凭据（用户名和密码）或检查源 IP 地址来完成。

• 授权 确认已通过身份验证的客户端可以访问的内容

使用哪个代理池、哪些国家、多少带宽、多少并发会话。

大多数讨论会把这两者混为一谈，但从操作层面看，这一区别很重要。客户端可以成功通过认证，却仍因授权限制（例如带宽上限或受地域限制的代理池）而被拒绝访问某个特定资源。

以下是用纯文本描述的概念性流程：

代理凭据存在于 HTTP 请求本身中，而不是像网站那样存在于单独的登录会话里。这是它与常规网页认证的一个重要区别：默认情况下没有 cookie，没有令牌刷新流程，只有附加在每一个请求上的请求头（或一个预先批准的 IP）。

代理认证的工作原理

每一个经过认证、发往代理的 HTTP 请求都遵循相同的通用请求-响应周期：

1. 客户端通过代理发送请求
2. 代理检查凭据是否有效
3. 如果缺失/无效 → 代理返回 HTTP 407
4. 客户端携带 Proxy-Authorization 标头重新发送请求
5. 代理会将凭据与其数据库进行验证
6. 代理将请求转发到目标站点
7. 目标站点响应 → 代理将响应转发给客户端

HTTP 407：需要代理认证

当客户端在未提供有效凭据的情况下发起请求时，代理会返回状态码 407 需要代理身份验证。这是代理专用的等价物，对应于 401 未授权 网站的响应。它告诉客户端：“我知道你想要访问谁，但你还没有向我证明你的身份。”

407 响应中包含一个 Proxy-Authenticate 标头，用于指定代理所期望的身份验证方案（Basic、Digest、NTLM 等）。

Proxy-Authenticate 与 Proxy-Authorization 的对比

这两个请求头很容易混淆，因为它们听起来几乎一模一样，但它们的作用方向恰好相反：

Proxy-Authenticate — 由代理发送给客户端，指定所需的身份验证方案和领域（realm）。

Proxy-Authorization — 由客户端发送给代理，包含实际的凭据（Basic 认证通常采用 Base64 编码，Digest 认证则为计算出的哈希值）。

典型的交互过程如下所示：

• 服务器 → 客户端：

• 客户端 → 服务器：

一旦代理验证了该头,它就会停止返回 407 状态码,并在该连接或会话的剩余时间内正常转发流量。

需要为轮换会话、地理定位和自动化提供灵活的代理认证？试用 NodeMaven，住宅、ISP 和移动代理低至 $3.50 起。

开始试用

代理认证方法

针对代理进行认证并没有唯一“正确”的方式。合适的方法取决于你的基础设施、你的代理类型，以及你对客户端环境拥有多大的控制权。

· 用户名和密码身份验证

客户端在每个请求中都发送用户名和密码，可以通过 Proxy-Authorization 标头中，或直接嵌入到代理 URL 里（http://username:password@gateway:port).

优势：

• 可从任何 IP 地址使用，无需将任何内容加入白名单
• 非常适合动态环境：CI/CD 流水线、云函数、轮换的云服务器
• 轻松管理具有不同权限的多个子用户
• 凭据可以编码会话参数（国家/地区、粘性会话 ID、州）

缺点：

• 凭据必须安全地存储和传输
• 对于不原生支持在 URL 中携带凭据的工具来说，设置过程比 IP 白名单稍微复杂一些

何时使用： 任何时候您的出站 IP 发生变化时。例如 NAT 后的本地开发、无服务器函数、分布式抓取基础设施,或者从多个地点工作的团队。了解 如何使用住宅代理 并使用用户名/密码身份验证。

· IP 白名单

代理不会发送凭据，而是将传入连接的源 IP 地址与一份已批准的名单进行比对。如果 IP 匹配，请求就会自动通过身份验证。无需任何请求头。

优势：

• 代码中零凭据，仓库或日志文件中没有任何可泄露的内容
• 简化了那些对代理身份验证头支持不佳的工具

缺点：

• 需要一个静态的、 专用 IP。对于使用动态 IP 的家庭连接或经常切换网络的笔记本电脑毫无用处
• 在分布式团队或自动扩缩容基础设施中难以扩展，因为每个新 IP 都需要手动审批

静态 IP 要求： 这是该方法最大的限制。它最适合具有固定出站 IP 的专用服务器、办公网络或 VPS 实例,而不适合住宅连接或临时的云工作节点。

· 基本（Basic）身份验证

Basic Auth 是用户名/密码代理认证背后最常见的方案。客户端将其拼接 username:password，将其以 Base64 编码，并在以下位置发送 Proxy-Authorization 标头。

它简单、被广泛支持，并且应始终在加密连接（HTTPS/CONNECT 隧道）上运行，以避免凭据在传输线路上以明文形式暴露。

· 摘要（Digest）身份验证

Digest 认证在 Basic 的基础上进行了改进，因为它从不发送密码本身。相反，客户端将密码与服务器下发的“nonce”组合起来，并对结果进行哈希处理。代理会重新计算相同的哈希值并进行比对。

它比 Basic 更能抵御被动嗅探，但受到自动化工具和代理库的普遍支持程度也较低。如果你已经通过 TLS 建立隧道，那么它在很大程度上是多余的。

·      NTLM

NTLM 是一种微软的质询-响应协议,最常见于企业 Windows 环境中,流量通过与 Active Directory 凭据绑定的内部代理进行路由。它很少用于商业数据中心代理或 住宅代理 服务，但如果你要与企业网络基础设施集成，就会遇到它。

·      Kerberos / SPNEGO

Kerberos(在 HTTP 中通常通过 SPNEGO 协商)是另一种企业级选项,它围绕由受信任的密钥分发中心 (Key Distribution Center) 颁发的基于票据的身份验证构建。它常见于采用单点登录的大型企业网络,但对于典型场景而言过于复杂 网络爬虫 或自动化代理使用场景。

·      OAuth 2.0

一些企业级和 API 网关式代理支持 OAuth 2.0，客户端会出示一个 bearer 令牌，而不是用户名/密码组合。

实际应用中，就代理身份验证而言，OAuth 通常会叠加在一个签发短期令牌的 API 之上，这些令牌随后被用来替代静态凭据。它增加了轮换和集中式吊销的能力，但相比 Basic 身份验证需要更多的集成工作，对于大型企业部署来说是值得的，而对大多数抓取或自动化项目则没有必要。

对比表

您应该选择哪种代理身份验证方法?

基于常见场景的快速决策指南：

• “我使用住宅代理。”

→ 用户名/密码认证。住宅 IP 会不断轮换，因此静态白名单跟不上变化。

• “我运行的是固定 IP 的专用服务器。”

→ IP 白名单。无需管理凭据，而且你的 IP 不会变化。

• “我大规模抓取网站数据.”

→ 用户名/密码，会话参数（国家/地区、粘性会话 ID）直接编码在用户名中，便于会话控制。

• “我自动化浏览器（Selenium/Playwright/Puppeteer）。”

→ 用户名/密码，通过浏览器原生的代理验证扩展或 context API 处理，请参阅下方针对具体工具的章节。

• “我的团队在多个办公室或家庭网络中工作。”

→ 用户名/密码。为每一个不断变化的 IP 设置白名单并不现实。

• “我需要企业级 SSO 集成。”

→ Kerberos/SPNEGO 或 OAuth 2.0，具体取决于你现有的身份提供商。

在住宅、ISP 和移动代理中使用统一的身份验证格式。只需 $3.50 即可开始使用 NodeMaven，并获得 750 MB 用于测试你的配置

开始试用

按代理类型的代理认证

不同的代理类型带有不同的实际限制，这会影响到哪种认证方法真正合理可行。

住宅代理

住宅代理 IP 属于家庭网络中的真实设备，因此它们会频繁轮换且不可预测。用户名/密码身份验证是这里的标准方式。粘性会话（在设定的时间窗口内保持同一个 IP，通常为 1–30 分钟）通常通过在用户名后附加会话 ID 来控制，而轮换会话则会在每次请求时或按设定的时间间隔自动分配一个新 IP。

ISP 代理

ISP 代理 将数据中心的连接稳定性与注册在住宅 ISP 名下的 IP 结合在一起。由于 IP 池比住宅代理更小、更稳定，用户名/密码和 IP 白名单都能很好地工作。白名单在这里之所以有吸引力，正是因为 ISP 的 IP 更为静态。

移动代理

移动代理 通过运营商网络（3G/4G/5G）路由流量，这意味着当运营商在各个基站之间重新分配地址时，IP 会不可预测地变化。因此实际上必须使用用户名/密码。没有稳定的 IP 可供加入白名单。

NodeMaven 通过单一一致的凭据格式，为全部三种代理类型提供基于网关的身份验证，因此在不同代理类型之间切换时无需从头重建你的身份验证逻辑。

常用工具的代理认证

Chrome / Firefox

浏览器默认会在对话框中提示输入凭据，这会破坏无头自动化。对于手动浏览，可以使用扩展程序，例如 代理自动认证 （或 SwitchyOmega式代理管理器）会存储凭据并自动回应提示。

Selenium

Selenium 的原生 选项 对象不接受 Chrome 的内联凭据。你需要 selenium-wire 或者一个解压后的扩展程序,用于注入 Proxy-Authorization 标头。

Playwright

Playwright 原生支持需要认证的代理。无需扩展程序。

Puppeteer

Python Requests

Scrapy

Node.js / Axios

curl

Postman

在某个请求配置下的代理设置中，启用自定义代理服务器，输入网关主机和端口，然后在“Proxy Authentication”部分添加凭据。Postman 会附加 Proxy-Authorization 标头。

代码示例

Java

纯 JavaScript（通过代理 agent 使用 fetch）

常见的代理身份验证错误

告别认证烦恼。NodeMaven 提供开箱即用的代理凭据、IP 白名单以及详尽的设置指南，套餐起价 $3.50

开始试用

NodeMaven 代理身份验证的工作原理

NodeMaven 会在控制面板中为每位客户签发一组唯一的网关凭据，由与你账户绑定的用户名和密码组成。

在此之后，认证通过以下两种方式之一进行：

• 用户名/密码

标准方法，几乎适用于所有使用场景，推荐使用。用户名本身即可编码会话参数：国家、地区、城市、ASN 以及粘性会话 ID，全部用连字符分隔（例如 customer-USERNAME-country-us-session-12345）。

• IP 白名单

适用于使用静态 IP（通常是数据中心或 ISP 配置）的用户，他们更愿意完全跳过凭据。

粘性会话 在设定的时间窗口内保持同一个 IP，这样多步骤工作流程（登录、结账、分页抓取）就不会在中途中断。 轮换会话 会自动分配一个新的 IP,这对于 IP 多样性比连续性更重要的大批量、单次请求抓取非常有用。

NodeMaven 同时支持两种身份验证方式，因为不同的基础设施需要不同的方法。例如，在临时容器上运行的 CI 流水线需要用户名/密码，而固定的 VPS 集群可能更倾向于白名单方式。

为什么选择 NodeMaven 提供已验证的代理

• 住宅、ISP 和移动代理采用统一一致的身份验证格式
• 通过相同的用户名语法控制粘性会话和轮换会话
• 无需单独的凭据集即可实现国家、地区、城市和 ASN 级别的定位
• 设置快速，凭据可从控制面板立即生成
• 兼容用户名/密码认证和 IP 白名单，因此基础设施的限制不会决定你能使用哪种代理类型
• 稳定的网关正常运行时间，专为长时间运行的抓取和自动化任务而设计

最佳实践

1. 始终通过 HTTPS/TLS 建立隧道 从而使凭据不会以明文形式暴露，尤其是在使用 Basic 认证时
2. 定期轮换凭据，尤其是对于共享的团队账户
3. 应用最小权限原则，只给每个子用户或项目分配它所需的代理池和带宽
4. 将凭据存储在环境变量中，切勿在源文件中硬编码
5. 使用密钥管理器 （Vault、AWS Secrets Manager、Doppler）用于生产环境部署，而不是 .env 文件 提交到代码仓库
6. 切勿记录完整的凭据，在应用日志中屏蔽密码
7. 有意识地设置会话 TTL，运行时间超出实际需要的粘性会话会浪费 IP 多样性

正在寻找可与 Selenium、Playwright、Python 等配合使用的已认证代理？从 $3.50 起使用 NodeMaven，并获赠 750 MB 流量

开始试用

常见问题