极安代理 - 2026实测：代理IP白名单已经添加，为什么仍然提示认证失败？

你有没有过这样的情况？

代理IP白名单已经添加，后台也亮着正常状态。结果脚本一跑，迎面就是一行：

```text
407 Proxy Authentication Required
```

然后开始删白名单、重新添加、换节点、重启程序。折腾一圈，407还在那里，稳得像写进了代码。

先说结论。

白名单已经添加却仍然认证失败，通常集中在四个地方：**填入的不是实际公网出口IP、出口IP发生了变化、白名单绑定错了业务，或者代码里仍然带着旧账密。**

固定云服务器使用极安代理的IP白名单更省心。本地调试、动态宽带和出口IP经常变化的环境，直接使用 `Authkey`、`Authpwd`，不用天天追着公网IP跑。

## 先别改代码，看看请求从哪里出去

白名单的逻辑很简单。

请求到达代理服务器后，系统读取来源端的公网出口IP，再拿它和后台白名单比对。对得上，放行。对不上，返回407。

这里最常见的坑，是把服务器网卡地址填进了白名单。

```text
192.168.1.15
10.0.8.21
172.17.0.2
```

这些都是内网地址。它们在局域网里有用，到了公网就像小区里的门牌号，快递出了小区谁也不认识。

进入实际运行程序的服务器，执行：

```bash
curl https://httpbin.org/ip
```

返回结果类似：

```json
{
  "origin": "203.0.113.20"
}
```

后台应该添加的是 `203.0.113.20`。

程序跑在Docker里，就进入容器执行。任务跑在远程服务器上，就登录远程服务器执行。不要在办公电脑上查完IP，再填给云服务器。两台设备很可能根本不走同一个出口。

## 公网IP明明正确，怎么还是407？

接着看三件事。

### 出口IP有没有变

固定云服务器的公网IP通常比较稳定。办公宽带、家庭网络、移动热点和部分动态云网络就没那么老实了，网络一重拨，出口可能直接换掉。

上午添加的是A，下午请求从B出去。后台记录没有错，当前请求也确实没权限。

在报错机器上重新执行：

```bash
curl https://httpbin.org/ip
```

把结果和白名单逐字核对。

如果出口经常变化，白名单就不太合适了。今天改一次，明天还得改。使用账密认证会轻松很多。

### 白名单是不是绑错了业务

同一个代理账号里，可能有多个套餐、多个业务编号，也可能同时存在短效代理和隧道代理。

白名单加在业务A里，程序调用业务B，系统不会因为大家都属于同一个账号就网开一面。

重点核对三个信息：

1. 白名单所属的业务编号  
2. 当前使用的是短效代理还是隧道代理  
3. 代码里的代理Host和端口来自哪项业务

以极安代理为例，短效代理通过接口提取IP，隧道代理使用固定入口，由云端调度出口。两类产品的地址、端口和业务配置要分别对应，不能东拼西凑。

后台看着都叫“代理”，网关可不认亲戚。

### 配置是不是还没同步

白名单保存后，需要同步到代理网关。刚点完保存就立刻测试，偶尔会遇到短暂的407。

等一两分钟再试即可。

不建议一分钟内连续删除、添加十几次。这样不会让配置生效得更快，只会让自己忘记现在测试的是哪一版。

## 代码里还藏着旧用户名和密码

不少项目最初使用账密认证，后来部署到固定服务器，又改成白名单。后台改好了，代码里却还留着旧配置：

```text
http://旧用户名:旧密码@代理地址:端口
```

请求发出时，客户端仍然会提交这组账密。密码错误、凭据过期或者格式解析失败，都可能继续返回407。

使用白名单时，先把代理地址改成：

```text
http://代理地址:端口
```

如果使用极安代理账密认证，则按下面的格式连接：

```text
http://Authkey:Authpwd@代理地址:端口
```

密码中如果包含 `@`、`:`、`#` 等特殊字符，需要先做URL编码。否则客户端可能把密码拆成代理地址的一部分，最后报一个看似很专业、实际很冤枉的认证错误。

Python里可以这样处理：

```python
from urllib.parse import quote

authkey = quote("你的Authkey", safe="")
authpwd = quote("你的Authpwd", safe="")
proxy = f"http://{authkey}:{authpwd}@代理地址:端口"
```

## 两条curl命令，先让代码休息一下

排查代理问题时，别一上来就翻业务代码。

采集程序里可能有连接池、重试、异步任务和环境变量。几个配置叠在一起，很容易越查越乱。

先执行第一条命令：

```bash
curl https://httpbin.org/ip
```

它用来确认本机公网出口IP。

再执行第二条：

```bash
curl -x http://代理地址:端口 https://httpbin.org/ip
```

如果第二条成功，并且返回的IP和第一条不同，说明白名单与代理链路都已正常。

此时程序仍然报错，问题大概率在代码里。重点检查：

- 代理地址有没有漏写 `http://`
- HTTP和HTTPS是否都配置了代理
- 程序是否读取了旧环境变量
- 连接池是否复用了旧连接
- 部署配置是否覆盖了代码参数

如果第二条仍然返回407，就继续查白名单、业务编号和认证方式。暂时别和Python互相伤害。

账密认证也可以单独测试：

```bash
curl -x http://Authkey:Authpwd@代理地址:端口 \
https://httpbin.org/ip
```

白名单模式能通、账密模式不通，查凭据。两种模式都不通，查地址、端口、业务状态和网络连通性。

## 403、407、429别混在一起

很多人看到请求失败，第一反应都是白名单有问题。其实几个常见状态码完全不是一回事。

| 状态码或提示         | 通常代表什么         | 先查哪里                   |
| -------------------- | -------------------- | -------------------------- |
| 407                  | 代理认证没有通过     | 白名单、账密、业务编号     |
| 401                  | 目标网站账号认证失败 | 登录状态和账号信息         |
| 403                  | 目标网站拒绝访问     | 请求频率、Cookie、请求特征 |
| 429                  | 请求次数过多         | 并发数和访问间隔           |
| Connection refused   | 地址或端口错误       | 代理连接信息               |
| Connection timed out | 网络、节点或额度异常 | curl连通性和套餐状态       |

只有407直接指向代理认证。

如果目标网站已经返回403或429，说明请求大概率已经通过代理到达了对方服务器。这时继续折腾白名单没什么用，应该转头检查并发、Cookie和采集节奏。

门已经进去了，只是保安没让你上楼。

## 不同运行环境，认证方式怎么选？

### 固定云服务器

优先使用IP白名单。

公网出口稳定，代码里不需要保存账号密码，适合长期运行的数据采集、价格监控和舆情任务。

### 本地电脑或动态宽带

推荐使用账密认证。

公网IP可能随着网络重拨发生变化。白名单今天能用，明天未必。账密认证不依赖固定出口，更适合开发调试。

### Docker和Kubernetes

不要把容器里的 `172.x.x.x` 填进白名单。

请求最终通常经过宿主机、NAT网关或集群出口。应当从容器内部查询公网IP，再把实际出口加入白名单。

### 多台服务器

先确认它们是否共用一个NAT网关。

共用出口，添加一条公网IP即可。各自出网，就要分别添加。别看服务器在同一个控制台里，就默认它们走同一扇门。

## 极安代理怎么配更稳？

可以按运行环境直接分两套。

固定服务器使用极安代理IP白名单。配置清楚，代码也更干净。公网出口不固定时，使用 `Authkey` 和 `Authpwd`，避免网络一变任务就停。

正式上线前，再守住三条：

1. 白名单必须添加到当前使用的业务中  
2. 短效代理和隧道代理不要混用地址、端口  
3. 先用curl跑通，再接入正式代码

如果返回了明确错误码，可以继续查看极安代理的[错误码说明](https://www.ja.cn/doc/2776.html)。先确认问题属于认证、连接还是目标网站限制，处理起来会快很多。

## 五分钟排查清单

白名单已经添加，程序仍然认证失败，按这个顺序查：

1. 在实际运行环境查询公网出口IP  
2. 与后台白名单逐字核对  
3. 检查白名单所属业务编号  
4. 确认代理Host和端口没有用错  
5. 删除代码里残留的旧账密  
6. 等待一两分钟后重新测试  
7. 使用curl绕开业务代码验证  
8. 根据407、403或429分别处理

这套流程不高级，也没有玄学。

代理认证排障最怕顺序混乱。一会儿改代码，一会儿换节点，最后连哪一步曾经成功过都记不清。先把代理链路单独跑通，再把它放回业务程序，问题自然会缩小。

## 最后说一句

白名单已经添加却仍然认证失败，先查公网出口，再核对业务归属，最后才轮到代码。

固定服务器使用极安代理白名单，动态环境使用账密认证。配置后先跑curl，确认代理出口确实发生变化，再启动正式任务。

别一报错就怀疑整个代理池。

多数时候，系统没坏。只是某个IP站错了队。