代理白名单不生效怎么排查，先确认出口 IP、控制台规则和 IPv4/IPv6

代理白名单不生效时，第一步不是反复重启工具，也不是马上更换代理。更有效的排查顺序是：确认请求真正使用的出口 IP，核对控制台白名单规则，检查 IPv4/IPv6 是否走了不同出口，再判断白名单缓存或配置生效延迟。只有把这几项分开，才能知道问题出在访问端、代理认证、控制台配置，还是生效时间。

白名单机制的本质，是让代理服务端只接受来自指定来源 IP 的连接。如果来源 IP 不是白名单里记录的那个地址，即使代理账号、端口和协议都正确，也可能出现 407、连接被拒绝、请求超时，或者只有部分工具能连通的情况。下面这套检查表适合在团队代理配置、服务器任务、采集脚本或账号网络环境切换前使用。

先判断失败信号属于哪一类

不同失败信号对应的方向不一样。407 更常见于认证、白名单或账号权限问题；连接超时可能是端口、协议、防火墙或网络路径问题；同一配置在本地能用、服务器不能用，通常要先比较两端出口 IP；只有某些目标站失败，则还要看目标站策略、访问频率和会话连续性。

如果失败信号集中在认证层，可以对照407 认证失败排查，先把用户名、密码、端口、协议和来源 IP 拆开验证。不要把 407 简单理解为“代理不可用”，否则容易把白名单问题误判成节点质量问题。

第一步：确认当前出口 IP 是否等于白名单 IP

白名单里应该填写的是发起连接设备的公网出口 IP，而不是内网 IP、本机网卡地址、代理出口 IP，也不是目标站看到的最终访问 IP。常见误区是把 192.168、10.0、172.16 这类内网地址填入控制台，或者把代理检测网站显示的出口 IP 当成来源 IP。

正确做法是：在实际发起代理连接的机器上，先不走代理访问一个公网 IP 查询接口，记录它显示的来源 IP；如果任务部署在云服务器、容器、办公网或家庭宽带下，还要确认是否经过 NAT、负载均衡、堡垒机或网关。团队协作时，建议把这个来源 IP 写进代理访问日志字段，方便后续追溯是谁、在哪台机器、用哪条规则发起了请求。

第二步：核对控制台规则是否真的覆盖了当前请求

控制台里有白名单，不代表当前请求一定命中了这条规则。需要逐项确认：白名单是否保存成功，规则是否绑定到正确套餐、子账号或端口，代理协议是否一致，是否同时启用了账号密码认证，是否有旧规则覆盖新规则。如果团队里有人同时调整了账号密码和白名单，排查时要先固定一种认证方式。

如果不确定应该使用白名单还是账号密码认证，可以先看访问控制方案的对照维度。白名单更适合来源 IP 稳定的服务器或固定办公网络；账号密码更适合来源 IP 经常变化的设备。两种方式混用时，记录规则归属和变更时间尤其重要。

第三步：检查 IPv4 和 IPv6 是否走了不同来源

很多白名单问题来自 IPv4/IPv6 混用。控制台里只添加了 IPv4，但请求库、系统网络或目标域名解析优先走 IPv6，就可能导致来源地址不匹配。反过来，服务器显示有 IPv6 地址，但实际代理连接走 IPv4，也会让排查结果前后矛盾。

建议分别记录 IPv4 来源 IP、IPv6 来源 IP、代理协议、DNS 解析结果和测试时间。如果刚切换过网络、服务器机房、弹性 IP 或出口线路，可以结合出口 IP 切换检查，把切换前后的来源地址、地区、协议和会话阶段放在同一张表里看。

第四步：给白名单生效和连接缓存留出观察窗口

有些控制台规则保存后需要短时间同步；有些客户端、连接池或脚本会复用旧连接。刚改完白名单就立即连续测试，可能看到旧规则、旧连接或缓存状态。更稳妥的做法是记录保存时间，等待一个明确窗口，关闭旧连接，再用同一台机器、同一协议、同一端口重新测试。

如果上线任务依赖白名单，建议先按代理灰度测试的方式用小流量验证。只要 407、超时、地区跳变或认证失败还没有收敛，就不要扩大到整批任务。

可复制的白名单排查记录表

如果团队使用多地设备、多台服务器或多个子账号，白名单规则应该和代理资源选择一起管理：固定来源适合白名单，来源经常变化就需要考虑账号密码认证或更细的访问控制。不要让多个团队成员临时修改同一条白名单却没有变更记录。

什么时候应该暂停继续测试

出现以下情况时，建议先暂停任务：来源公网 IP 无法确认，IPv4 和 IPv6 结果不一致，控制台规则归属不清楚，407 在多台设备上重复出现，或者旧连接关闭后仍无法命中白名单。此时继续扩大请求量只会增加误判成本，应该先把来源地址、认证方式和规则绑定关系固定下来。

代理白名单不生效，通常不是一个单点问题。把出口 IP、控制台规则、IPv4/IPv6、缓存延迟和错误码拆开记录，团队就能判断该等待同步、调整白名单、回退到账号密码认证，还是重新规划固定来源网络。排查目标不是证明某个节点可用，而是让访问控制规则和真实请求路径一致。