“已经把代理 IP 加入白名单，为什么仍然 403？”这类问题最容易卡在“IP”指代不清。一次请求至少可能经过客户端、代理入口、代理出口和目标服务四层网络，白名单系统又可能按来源地址、账号、端口、CIDR 或 API 密钥判断。先明确目标服务实际看到的地址，再谈放行范围。
先画出请求经过的四类地址
- 客户端来源地址：发起请求的电脑、VPS或办公网络公网出口。
- 代理入口地址：客户端连接的代理主机和端口，可能是共享入口。
- 代理出口地址：代理向目标服务建立连接时使用的公网地址，轮换产品可能不断变化。
- 目标服务记录的地址：应用层日志、负载均衡或 CDN 看到的 TCP 对端，未必等于请求头里的某个字段。
如果白名单配置在目标 API，而目标看到的是代理出口，那么把本机地址或代理入口加入白名单都不会生效；如果白名单配置在代理网关，则可能恰好相反。
用日志和对照请求确认目标看到什么
先使用一个固定节点、一个目标路径和低频请求，记录时间、请求 ID、状态码与脱敏后的地址。应用日志或负载均衡日志应作为主要证据；不要把 X-Forwarded-For 当成可信来源，因为客户端可以伪造，除非它由受信任的反向代理链重写并经过校验。
# 仅用于查看代理出口的示例，占位符不代表真实检测服务
curl -sS --proxy http://USER:PASS@PROXY_HOST:PROXY_PORT
"https://example.test/ip"
# 对比直连和代理时目标服务的日志
curl -i --max-redirs 0 --proxy http://PROXY_HOST:PROXY_PORT
"https://api.example.test/health"若直连成功、代理返回 403，先确认目标服务是否按出口地址控制；若代理入口握手就失败，问题在代理侧白名单或认证；若请求到达目标但应用拒绝，则继续查 CIDR、账号权限和接口策略。
检查 IPv4/IPv6、NAT 与地址格式
同一台机器可能同时有 IPv4 和 IPv6 出口。应用选择 IPv6 时，服务端看到的地址与控制台显示的 IPv4 不同；代理也可能把多个用户通过 NAT 汇聚到一个出口。把 203.0.113.10/32、203.0.113.10、IPv6 压缩写法和带端口的文本混用，都可能导致匹配失败。
核对白名单接受的格式：单地址、CIDR、地址段、端口范围还是标签。不要为了省事直接放行 0.0.0.0/0 或 ::/0。如果业务确实需要多个轮换出口，应改用供应商提供的稳定出口组、账号级鉴权或短期授权机制，而不是无限扩大网段。
排查规则优先级和缓存
防火墙、安全组、反向代理、API 网关和应用自身可能各有一层白名单。某一层先返回 403 时，后面的规则根本不会执行。检查拒绝响应的 Server 标识、网关 Request-ID、访问日志和规则命中顺序；确认修改的是生产环境，而不是测试项目或错误的区域。
部分网关会缓存鉴权结果，配置变更后需要等待规定的传播时间或执行受控刷新。刷新前保存旧规则和回滚值，避免在高峰期反复发布。对轮换代理，还要确认“白名单有效期”是否短于会话时间。
建立最小权限的验收流程
- 固定一个节点和一个测试账号，只访问健康检查或授权接口。
- 在目标日志中确认 TCP 对端地址、地址族、端口和请求 ID。
- 只添加该地址或最小 CIDR，等待配置传播后重试。
- 分别验证直连、代理入口和代理出口场景，记录哪一层返回拒绝。
- 确认业务通过后设置过期时间、变更审批和回滚规则。
白名单的目标是限制可信来源，不是替代认证。即使地址已放行，也应继续使用 API 密钥、短期令牌、TLS 和审计日志；代理服务商更换出口或目标平台调整策略后，还需要重新验收。
常见问题
把代理主机 IP 加入白名单却还是 403，为什么？
目标服务通常看到的是代理出口 IP，而不是客户端连接的入口地址。应以目标日志中的 TCP 对端为准。
可以把 X-Forwarded-For 写成已授权地址吗？
不可以。除非请求来自受信任且正确配置的反向代理，否则该头部可被伪造，不能作为安全白名单依据。
为什么同一代理一会儿能访问、一会儿被拒绝？
可能是出口轮换、IPv4/IPv6切换、白名单传播延迟或会话绑定变化。用固定节点和请求 ID 做时间序列对照。
白名单应该放行单个地址还是整个网段？
优先单地址或供应商明确的稳定出口组。只有在地址段归属、变更机制和风险都清楚时，才考虑最小必要的 CIDR。
