你在公司敲下一行请求，页面秒开。这中间到底发生了什么，多数人说不上来。尤其是挂上代理之后，链路从"一条直线"变成了"三段折线"，任何一段出问题，表现都是同一个结果：卡住、超时、报错。
这篇就把这条链路一段一段拆开讲。不讲那些云里雾里的定义，只讲你按下回车那一刻，机器之间到底握了几次手、验了几回身份、改了哪些字段、数据又是怎么拐回来的。
先把三个角色摆到台面上
一次带代理的请求，牵扯到三方：你的程序、代理服务器、目标站点。
不挂代理时，是"你的程序 → 目标站点"点对点。挂上代理后，你的程序不再直接找目标站点，而是先跟代理服务器商定："帮我跑一趟。"代理服务器拿过这个请求，用自己的身份再去跟目标站点打交道，拿到结果后原样送回给你。
这里有个新手常搞混的点：目标站点看到的是代理服务器的IP，不是你的IP。你本机的地址在整条链路里被"藏"在了第一段里，出不了第二段。所以你在程序里换一个代理IP，对方眼里就是一个全新的访客——这也是公开数据采集、市场研究这类场景需要代理IP的根本原因。
握手：连接建立之前，双方要先"对暗号"
无论走不走代理，第一步都是建连接，也就是常说的 TCP 三次握手。这一层代理帮不了你，它就是网络通信的底层规矩：客户端发个 SYN，服务端回 SYN+ACK，客户端再回 ACK，三次之后通道才算通。
区别在于，挂代理时这条路走了两遍。你的程序先跟代理服务器握手，握手成功后，代理服务器再单独跟目标站点握手。两段握手是串行的，任何一段慢，整体就慢。这也是为什么同一个代理IP，访问A站很快、访问B站很慢——慢的不是IP本身，是代理服务器到B站那一段。
如果你访问的是 HTTPS 站点，还多一层：你的程序会先向代理发一条 CONNECT 请求，说清楚"我要连哪个域名哪个端口"。代理服务器确认可以之后建隧道，之后的加密内容它只做搬运，看不懂内容。这一步很关键，它意味着你抓到的 HTTPS 数据在代理这一段依然是密文。
认证三选一，配置错了就报 407
握手完成，接下来是"验明正身"。代理服务器得知道你是谁，才肯替你跑腿。常见的认证方式有三种：
IP 白名单——把你自己服务器的公网IP报给服务商，加进白名单。之后从这个IP来的请求直接放行，程序里一行认证代码都不用写。省事，但换机器就得重新报备。
账号密码——把用户名密码塞进代理地址里。灵活，哪台机器都能用，代价是密码会出现在代码和日志里，别往公开仓库里提交。
提取链接——调一个接口，每次拿到一个可用IP和端口，短效动态IP基本都这么用。适合请求量波动大、需要频繁获取新IP的场景。
认证没过，代理会直接回一个 407 Proxy Authentication Required。很多人第一次调试看到这个状态码还以为是目标站点的问题，其实根本没出门。
import requests
# 账号密码认证：把用户名密码拼进代理地址
proxies = {
"http": "http://用户名:密码@代理地址:端口",
"https": "http://用户名:密码@代理地址:端口",
}
try:
r = requests.get("https://example.com/list", proxies=proxies, timeout=10)
print("状态码", r.status_code)
print("耗时", round(r.elapsed.total_seconds(), 3), "秒")
except requests.exceptions.ProxyError:
print("代理这一段没通：检查IP是否过期、账密是否正确")
except requests.exceptions.Timeout:
print("握手超时：多半是代理到目标站点这一段慢")
这段代码里我特意把 ProxyError 和 Timeout 分开捕获。理由很实际：ProxyError 说明你连代理都没连上，Timeout 说明代理连上了但没等到结果。两种错误的排查方向完全不同，混在一起看只会白折腾。
转发：请求头在代理这一跳被悄悄改动
认证过了，代理服务器拿着你的请求往目标站点发。这里有个细节值得知道：代理不是把原始请求一字不改地转出去，它通常会加上几个标记字段。
比较常见的是 Via，记录请求经过了哪些代理；还有 X-Forwarded-For，很多代理会往里写真实客户端IP。也就是说，并不是所有代理都做到了"完全隐身"——取决于服务商怎么配置。你在做公开数据采集时如果发现请求被识别得特别快，可以先去看看这两个字段有没有被带出去。
另外，目标站点看到的源IP、User-Agent、请求频率、Cookie 组合，是综合判断的。换个IP但请求头里还留着上一轮的特征，一样会被当成同一个来源。这块没必要钻牛角尖，把IP、请求头、访问节奏三者一起调，比死磕某一个字段管用得多。
| 观察点 | 直连时 | 走代理时 |
|---|---|---|
| 目标站点记录的来源IP | 本机公网IP | 代理服务器IP |
| 连接建立次数 | 一次握手 | 两段握手，串行 |
| 请求头标记 | 无代理相关字段 | 可能带 Via、X-Forwarded-For |
| 超时风险点 | 本机网络质量 | 本机到代理 + 代理到目标，两段都要算 |
| 出错时的表现 | 直接连不上 | 407 认证失败、502 代理转发失败、超时 |
回传：数据怎么原路返回
目标站点处理完，把响应吐回来。注意方向——响应不会直接飞到你机器上，它是先回到代理服务器，代理再沿着刚才那条隧道送回给你。
所以整条链路其实是四步：建连接、验身份、转请求、回响应。任何一步断掉，你看到的都是失败。而且响应体越大，回传这一段越慢。抓一页几KB的HTML和拉一个几百KB的JSON，用的可能是同一个IP，但耗时能差好几倍，问题往往不在IP，在回传体积。
这里给个实操建议：首次接入一个新代理时，别急着上量。先跑50次请求，把状态码、耗时、失败原因分别记下来。状态码里 200 正常、403 被拦、407 认证失败、429 请求太密、502 代理转发失败，五个码基本能定位九成问题。花十分钟做这件事，比后面调两小时强。
神龙HTTP的个人中心里就有可视化的用量统计和实时监控，能看出请求趋势和异常波动，配合自己记的这份小表，排查起来省不少力气。它家是国内三大运营商正规授权的线路，支持 HTTP/HTTPS/SOCKS5 三种协议，3000万+的IP储备、可用率标称99.9%，对需要长时间挂着跑采集任务的场景来说，稳定性比峰值数字更值得看。
三条产品线，对应三种链路节奏
同一个"代理IP"，生命周期不一样，用起来的体感差别很大。选错了，代码本身一点问题没有，就是跑不动。
| 类型 | IP存活时长 | 链路特点 | 适合什么 |
|---|---|---|---|
| 短效动态IP | 分钟级 | 每次提取拿到新IP，握手成本分摊在多次请求里更划算 | 公开数据采集、规模较大的批量抓取 |
| 长效静态IP | 几小时到几天 | 同一IP可复用多次，会话连续性好 | 需要保持登录态、连续翻页的任务 |
| 固定IP代理 | 长期不变 | IP恒定，链路最可控 | 对接固定接口、需要稳定出口的业务 |
怎么判断自己该用哪种？有个简单的问法：你这批请求，需不需要"记得上一步"。不需要，就用短效动态，IP池大、换得勤；需要维持会话，就上长效静态；对端要求出口IP固定，那就只能固定IP代理。
接入上没那么多讲究。神龙HTTP的API兼容主流爬虫语言，官方有文档和示例代码，把上面那段 requests 里的代理地址换成实时提取出来的IP和端口就能跑。300+城市级定位这个能力，在做区域性的市场研究时挺有用——想看不同城市返回的结果差异，直接按城市取IP就行。
常见问题
Q：代理IP和VPN有什么区别？我该用哪个？
两者思路不同。这类工具的重点是"让请求从另一台服务器出去"，适合程序化的公开数据采集、市场研究；日常办公联网用公司网络就行。我们的场景是写代码抓公开数据，所以讲的是代理IP这一套。
Q：为什么换了IP还是被拦？
先看三件事：请求头是不是还带着上一轮的特征、访问间隔是不是太密、Cookie有没有跟着串。IP只是判断维度之一。另外确认一下代理有没有把真实IP写进 X-Forwarded-For，有的话换服务商配置更彻底。
Q：报 407 是什么原因？
认证没过。三个方向查：IP白名单里有没有你这台机器的公网IP、账号密码有没有拼错或过期、提取链接拿到的IP是不是已经失效了。407 是代理直接回的，请求根本没到目标站点，别去查对方网站。
Q：为什么同一批请求，有的快有的慢？
大概率是回传体积和握手次数在起作用。响应体大的请求，回传那一段天然更慢；另外每次请求都要重新握手的话，往返延迟会叠加。想稳一点就控制并发、给超时留足余量，别用一个固定值卡死所有请求。
