代理端口不会放行未经授权的连接——否则任何得知地址和端口的人都能使用它。服务商提供两种向端口证明「这是我」的方式：固定的账号密码组合，或者把客户端的出口 IP 加入白名单。这两种方式并不能互相替代：各自的失效方式、泄露风险点和团队协作下的便利性都不同。下面说清楚该按什么基础设施来选。
两种方式各自如何工作
账号密码是随连接请求本身一起发送的——写在代理 URL 里（login:password@host:port），或作为单独的授权头。端口在每次连接时都会校验这组凭据，与请求来自哪里无关。这是一种典型的「你是谁」式校验，绑定的是凭据而不是连接来源。
IP 白名单的原理不同：端口预先持有一份允许免密码连接的外部地址列表。校验的不是「你是谁」，而是「你从哪来」——比对的是发起 TCP 连接的那个 IP。如果客户端的出口地址不在列表里，连接会在任何授权尝试之前就被拒绝。
什么时候 IP 白名单更省心
只要客户端的出口地址稳定，白名单就能省下不少事：独立服务器、有静态 IP 的办公网络、云端 VPS 都属于这种情况。在后台录入一次地址后，此后每个脚本都能免密码连接，配置文件更简洁，也不会有人不小心把账号密码提交进代码仓库。对于常年运行在同一台主机上的服务端自动化任务，这是成本最低的方案。在依赖白名单之前，值得先确认该通道本身是否有稳定的质量指标——否则地址稳定，连接质量却在悄悄下降。
缺点只有一个，但足以致命：一旦服务器出口 IP 发生变化——主机商在重启后分配了新地址、迁移到另一个数据中心、运营商套餐变更——白名单会立刻且毫无预警地不再识别该客户端。脚本得到的是连接被拒绝，而不是授权错误，这更难排查：代码看起来没问题，代理看起来也已付费，流量却根本跑不通。
什么时候必须用账号密码
出口地址是动态的，白名单就从原理上失效了。通过 DHCP 重连的家庭宽带、移动网络接入、每天从新地点上线的笔记本电脑——这些场景下客户端 IP 变化的速度远快于后台白名单能更新的速度。此时账号密码是唯一可行的方式：授权与请求实际来自哪里无关。
第二种情况是多台设备共用一组凭据。当多名员工或多台地址各异且不可预测的服务器要通过同一个代理工作时，逐个把 IP 加入白名单效率很低；在具备自动扩容的云环境下，这几乎不可能实现——新实例会动态获得新地址。通过反检测浏览器管理账号的团队也是同样的道理：每位员工都有自己的账号环境和 IP，逐一录入白名单并不现实。
账号密码泄露的风险
账号密码有一个白名单没有的弱点：这组凭据本身就是可能泄露的秘密。它会出现在调试时的应用日志里、终端命令历史里、误提交配置文件后的公开代码仓库里、转交权限时的聊天记录里。拿到这组凭据的人可以从任意 IP 连接——代理只核对密码是否正确，不核对请求来自哪里。
相比之下白名单更稳固：即便有人得知代理的地址和端口，只要自己的出口 IP 不在列表中就无法连接。这里没有可以复制带走的秘密，只有一份外人无法控制的基础设施绑定关系。
团队协作该怎么选
混合方案通常比单一方案更贴合实际。对于稳定的服务器基础设施，用白名单：配置文件里不留秘密，泄露风险更低。对于移动办公或居家办公的员工、测试环境以及通过 API 的集成，用账号密码——但要定期轮换：如果凭据曾在聊天中发送过或用于测试，应当更换而不是一直沿用。某个端口具体支持哪种方式、对应多大流量额度，在后台分配地址时就能查到。
常见问题
同一个端口能同时用两种方式吗？
端口通常在分配时就固定了一种校验方式，但完全可以为不同场景保留多个端口：一部分给服务器用白名单，一部分给移动或出差场景用账号密码。
代码没改，代理却突然连不上了，为什么？
最常见的原因是加入白名单的那个出口 IP 变了。检查服务器当前的出口地址，并与后台列表核对；主机商在重启或迁移后可能会重新分配地址。
配置文件里存密码安全，还是依赖白名单安全？
如果基础设施稳定，白名单更安全：配置文件里不会留下可被复制的秘密。如果客户端地址会变化，账号密码就无法避免——这种情况下应把它存在环境变量或密钥管理工具里，而不是明文写进代码仓库。
在代理专区可以按自己的基础设施选择认证方式并开通访问。同一页面也能看到哪些通道支持白名单、哪些只支持账号密码分配——这一点值得在付款前核实，而不是等到第一次连接被拒后才发现。