每个代理连接都需要某种方式来验证您的使用授权。两种标准方法：注册您的 IP 并跳过凭据验证，或在每次请求时使用代理服务器的用户名和密码进行身份验证。
仅 IP 认证在地址固定时表现出色。但如果您使用的是家庭宽带、在不同网络间切换的笔记本电脑，或动态 IP 的 VPS——您需要一种不会因地址变化而中断的认证方式。这就是用户名/密码认证的用武之地。
基于凭据的认证工作原理
当您的软件连接代理时，代理会要求提供访问凭证。使用 HTTP 代理认证时，客户端会发送一个 Proxy-Authorization 头，其中包含以 Base64 编码的用户名和密码。代理验证凭据，如果匹配——流量即可通行。以下是一个 curl 快速示例： curl -x http://username:password@proxy-address:port https://example.com ——或在 Python requests 中： requests.get("https://example.com", proxies={"https": "http://username:password@proxy-address:port"}).
使用 SOCKS5 代理的用户名和密码认证时，流程略有不同。SOCKS5 在自身的握手阶段处理凭据——这是在任何网络流量开始之前的独立步骤。客户端声明需要进行认证，发送用户名和密码，代理随后返回成功或失败的响应。只有认证通过后，实际的连接才会建立。
两种方法实现同一目标：证明您有权使用该代理，无论您从哪个 IP 地址连接。
为什么使用凭据认证而非纯 IP 认证
纯 IP 模式更简单——无需密钥，软件中无需额外配置。但它要求您拥有静态公网地址。一旦 ISP 轮换了您的 IP，访问将立即中断，直到您更新白名单为止。
用户名/密码认证消除了对固定 IP 的依赖。您的代理凭据可以在任何网络环境下使用：办公室、咖啡店、甚至不同的国家。只要凭据正确，且您的 IP 在已注册地址的 /21 子网范围内，连接就能顺利建立。大多数代理服务商将凭据认证限制在单个白名单 IP 或极小的 /32 范围内——而 FineProxy 的 /21 子网方案覆盖 2,048 个地址，因此动态 IP 轮换几乎不会中断您的会话，为您提供市场上少见的灵活性。
这对以下场景尤为重要：
- 在不同 Wi-Fi 网络间切换的笔记本电脑和移动设备
- ISP 每天分配新地址的家庭宽带连接
- 团队成员从不同地点连接的多人协作场景
- 在 IP 不断变化的云实例上运行的 CI/CD 流水线
FineProxy 的工作方式
IP 注册在我们的平台上是必需的——它是系统识别客户的基础。当您在此基础上添加用户名/密码认证后，代理将接受来自您注册地址 /21 子网内任意 IP 的连接。
这意味着 2,048 个地址。大多数 ISP 的动态 IP 轮换范围远小于此，因此实际使用中，您的连接无需任何手动更新即可持续正常工作。
FineProxy 在我们提供的所有协议上均支持凭据认证：HTTP、HTTPS 和 SOCKS5。对于 HTTPS，每个 IP 都拥有独立的 SSL 证书，因此即使使用凭据认证，您的客户端与代理之间的加密连接依然安全可靠。
购买完成后，您可以立即在控制面板中获取凭据。格式非常简单：HTTP/HTTPS 使用 username:password@proxy-address:port，或在 SOCKS5 客户端的认证设置中进行配置。
购买完成后，凭据会立即显示在您的控制面板中——格式为 username:password@address:port，可直接粘贴到浏览器、脚本或自动化工具中使用。
妥善保管凭据
用户名/密码认证的缺点在于凭据的存在本身——而凡是存在的东西就有泄露的可能。以下是一些实用的安全建议：
请使用环境变量代替在脚本中硬编码凭据。export HTTPS_PROXY=”http://user:pass@proxy:port” 可以将密码从源代码中分离出来。
切勿将代理凭据提交到 Git 仓库。即使是私有仓库，也可能被分享、克隆或备份到您无法控制的地方。
如果您的工具支持，建议在运行时从密钥管理器中动态获取凭据，而非将其存储在配置文件中。