2.24 元/月和 6 元档差 3.76 元，慢下来的那几秒不在这个差价里：CDN 按「谁在问」发牌，出口换了城市、解析地还留在原地，一个页面的几十个资源就得从远端一趟趟取回来。
🔗 快速入口：一站式注册入口（24 家平台自助开通） ｜ 价格中心（全平台横向比价） ｜ 代理工具中心（客户端与配置教程）
| 解析地决定 | CDN 把你算作哪个省的访客，据此挑节点 |
| 出口地决定 | 数据实际从哪台机器出发、走哪条路到节点 |
| 两头对齐时 | 节点就在出口隔壁，绕路消失，首屏少 4 个往返 |
先把调度那一秒拆开看清，再把绕路折成时间和钱，然后给三条能直接贴进终端的命令，最后说清楚哪些站其实不用管。
调度发生在那一秒：谁在替你报位置
浏览器打开一个网址，第一步不是连服务器，是先问「这个域名在哪」。这一问不是你自己问的，中间有一层递归解析器代你问。
递归解析器报出去的是它的地址，不是你的
你填的 DNS 不管是运营商给的、还是手动改成公共 DNS，最终向权威服务器提问的都是那台递归解析器。权威服务器（大型站点背后就是 CDN 的调度系统）看到的来源地址是递归解析器的出口，它据此判断「这个访客大概在哪个省、哪个运营商」，然后返回一台距离合适的节点 IP。
这里有个很多人没意识到的细节：部分公共 DNS 会带上 EDNS Client Subnet，把你的网段一并递给权威，让调度更贴近你本人；不支持的公共 DNS 只报自己的机房位置，调度就按那台机器的位置来。所以在同样的网络下，只换一个 DNS，拿到的节点城市就可能变。
解析地和出口地分开，绕路就出现了
代理只改一件事：让请求从别的地址发出去。它不改 DNS 这一问发生在哪。装了代理软件、用系统代理或浏览器插件挂上去，解析通常还在本机、还走本地那条 DNS——于是 CDN 认为你在原地，把内容放在你家门口那台节点上；而真正来取内容的是几百公里外的出口。往返就这么被拉长了。
反过来，如果让解析也走隧道（远端解析，或者整机接管把 DNS 一起带进隧道），CDN 认为你在出口所在的城市，返回的节点就在出口隔壁，绕路自然消失。代价是解析质量交给了代理那一侧，对方 DNS 不给力时会慢在解析这一跳上——两头都不占，只有对齐才划算。
有的 CDN 根本不看 DNS
调度不是只有一种做法。三类常见方式，换出口之后的表现完全不同：
| 调度方式 | 依据什么判定 | 换出口后会变吗 | 典型场景 |
|---|---|---|---|
| DNS 调度（GSLB） | 解析请求的来源地址 | 解析跟着出口走才变，否则不变 | 国内绝大多数商业 CDN |
| Anycast 宣告 | BGP 路由把同一 IP 引到最近机房 | 会，跟着出口的网络位置自动变 | 海外大站、公共 DNS 本身 |
| HTTP-DNS | 客户端 SDK 主动上报自身信息 | 看 SDK 上报的是哪个地址 | 部分播放器、下载器、App |
所以「换了出口还是慢」有两种完全不同的原因：一种是调度方式压根不吃 DNS（anycast），换出口本来就会自动就近，你慢在别处；另一种是吃 DNS，但解析没跟着换，节点一直没动。分不清这两者，后面怎么调都是盲调。
DNS 缓存会把旧答案留一段时间
还有一层延迟：解析结果会被递归解析器按 TTL 缓存，常见几分钟到几小时。你换了出口、也把解析切到了远端，手上拿到的可能还是上一个节点地址，直到缓存过期。本机还有一层系统 DNS 缓存，Windows 上是 ipconfig /flushdns，macOS 与 Linux 各有自己的清理方式。换完配置先清一次，再看结果，否则验的是旧账。
这笔绕路怎么折算：一个页面的往返账
绕路不是抽象的「感觉慢」，能拆成往返次数和带宽时延乘积两项。
第一个字节之前，先跑完四趟往返
一次 HTTPS 请求在拿到第一个字节之前，至少要跑完解析、建连、握手这几趟：解析 1 个往返，TCP 建连 1 个往返，TLS 握手 1 到 2 个往返，然后才轮到服务器处理并回第一个字节。
| 阶段 | 往返数 | 同城 20 毫秒 | 跨境 200 毫秒 |
|---|---|---|---|
| DNS 解析 | 1 | 0.02 秒 | 0.2 秒 |
| TCP 建连 | 1 | 0.02 秒 | 0.2 秒 |
| TLS 握手 | 1–2 | 0.02–0.04 秒 | 0.2–0.4 秒 |
| 首字节返回 | 1 | 0.02 秒 | 0.2 秒 |
| 合计 | 4–5 | 0.08–0.10 秒 | 0.8–1.0 秒 |
这张表是算术，往返值按 20 与 200 毫秒两档代入，实际以你自己的测试为准。它说明一件事：跨省绕一趟，光「开始下载」之前就差出将近一秒，人多时这点差距会被放到每个页面上。
四十个资源不是四十次握手，看的是版本
老站还在用 HTTP/1.1：浏览器对同一域名开 6 条左右连接，几十个静态资源要排队，40 个资源大约排 7 轮，每轮一个往返。这时候绕路是乘法的，往返变大，轮数不变，总时间按倍数涨。
现在多数站升级到 HTTP/2 甚至 HTTP/3，一条连接多路复用，资源不再排队，握手次数降到一次。绕路的代价换了个形态：变成带宽时延乘积的限制——单条连接能跑多快，约等于发送窗口除以往返时延。往返从 30 毫秒涨到 80 毫秒，同一条线能跑满的速率就掉到不足四成。
换节点等于缓存清零
CDN 每台节点各自缓存一份内容。你被调度到 A 节点，图片和脚本在 A 上有缓存，命中很快；出口一漂，落到 B 节点，B 上这些对象是冷的，全都要回源站取一遍。
回源这一段最不受你控制：源站并发有限，缓存穿透的瞬间反而更慢。所以常见现象是「刚换完 IP 那几分钟特别卡，过一会又好了」——不是线路在恢复，是 B 节点把缓存攒起来了。
四种症状，指向四种不同的错位
把症状和原因对上，比盲调配置快得多：
| 症状 | 错位在哪 | 先查什么 |
|---|---|---|
| 测速 20 毫秒，开网页要三秒 | 解析地在本地，出口在外地 | remote_ip 与解析结果是否同城 |
| 页面文字出来了，图片一张张慢慢刷 | 静态资源域名走的是另一套 CDN | 图片域名单独测一遍连接地址 |
| 换完出口那几分钟最卡，之后恢复 | 新节点缓存是冷的，在回源 | 响应头 age 是不是很小 |
| 换了城市，速度一点没变 | 该站是 anycast，或解析没跟着走 | 解析结果是否还是一串老地址 |
三个数就能验出来
不用抓包，不用装监控，三条命令足够定性。命令里的目标站换成你自己业务实际访问的那一个。
先把「连到了哪台机器」打出来
curl -so /dev/null -w '%{remote_ip} %{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer}\n' https://目标站/
第一个值是实际建立连接的机器地址，后面四个是解析、建连、握手、首字节各自花了多少秒。挂上代理再跑一次，两行一对比，时间涨在哪一段立即现形。
再拿解析结果和出口城市对照
dig +short 目标站，或者 Windows 下 nslookup 目标站。把返回的地址与 remote_ip 比一比：两个地址在同一个城市、同一个运营商，说明节点就在出口旁边；解析结果在你家所在省、remote_ip 在别的省，就是典型的错位。
缓存命中率：age 与 x-cache
curl -sI https://目标站/任意静态资源，看响应头里的 age、x-cache、cf-cache-status、via。age 只有几十秒说明刚回源过，缓存是冷的；age 上千秒说明这份对象在这台节点上待了很久。同一个 URL 连查两次，第二次还报未命中，基本可以判定你每请求都落在不同节点上。
| 命令 | 看哪一列 | 判据 |
|---|---|---|
| curl -w remote_ip | 实际连接地址 | 是否与出口同城同运营商 |
| dig +short | 解析到的地址 | 与 remote_ip 是否一致 |
| curl -I 看 age | 缓存待了多久 | 过小＝冷缓存，正在回源 |
| tracert -d ／ mtr | 前几跳的出口城市 | 第一跳是否已离开本地 |
哪些站其实不用管
不是所有业务都值得为这一层花时间。三种情况可以直接跳过：目标站用 anycast 的（海外大站居多），换出口它自己会就就近；业务只调接口、不加载页面资源的，没有几十个静态资源要取；访问频率低、单次请求几十 KB 的，多一个往返也就是几十毫秒。
真正值得管的是这三类：网页类业务要看首屏、图片和脚本几十个；同一目标站要反复访问、命中率直接影响耗时；按城市取内容、节点位置会改变返回结果的。
收敛方式：让两头对齐，或者干脆不管
解决错位只有两条路——让解析跟着出口走，或者让出口选在业务真正需要的位置。两条都能落地，代价不同。
三种接法，域名分别由谁解析
同样是挂代理，域名这一问发生在哪，取决于是哪种接法：
| 接法 | 域名谁解析 | 出口 | 调度结果 |
|---|---|---|---|
| 应用内 SOCKS5，本地解析 | 本机 / 本地 DNS | 代理出口 | 节点留在本地，绕路 |
| 应用内 SOCKS5，远端解析 | 代理那一侧 | 代理出口 | 节点贴近出口，对齐 |
| 整机接管（L2TP / TUN） | 隧道内 DNS（需确认已配） | 代理出口 | 多半对齐，前提是 DNS 没漏在本地 |
| 浏览器插件 / 系统代理 | 本机 | 代理出口 | 节点留在本地，绕路 |
整机接管那一行要单独看一眼：很多人拨上号就在跑，DNS 其实还是本机在问，隧道只带走了流量。要确认隧道内的 DNS 指向哪，有的客户端要在设置里单独填，有的默认继承拨号下发的地址。
出口选城市，比选带宽更影响首屏
在带宽都够用的前提下，出口离目标站近不近，直接决定那 4 个往返的长度。挑线路时先定城市，再定带宽档位，顺序反了就是花钱买了用不上的带宽。站内按城市分档的平台不少，城市覆盖越细价格越高，下单前把价格表页那一列看清楚，别默认「买了 100 兆就哪里都能跑」。价格如有调整，以平台后台实时显示为准。
别做的三件事
第一，别为调度去改 hosts。把某个域名写死到一台节点的地址上，等于自己放弃了调度，节点哪天调整你也不知道，还可能踩到已下线的机器。
第二，别为了「让 CDN 认我」去关掉站点侧的加速。错位是本地出口与解析地的问题，动站点的 CDN 配置解决不了，只会把别人的优化也一起拆了。
第三，别用 ping 的往返当网页耗时。ping 走的是 ICMP，只测了到某台机器的一次往返，不包含解析、握手和服务器处理，两者能差出一个数量级。
官方入口与相关页面
验完再买是这条路子上最省钱的顺序，几个页面对应四种不同用途：
| 用途 | 页面 |
|---|---|
| 横向比价、看各档起价 | 价格中心：24 家平台比价，全部免费测试 |
| 客户端下载与配置 | 代理工具中心：Win／安卓／iOS 客户端与教程 |
| 验出口与线路质量 | IP综合检测中心：IP质量／线路／测速／业务模拟 |
| 自助开通、续费、调换 | 聚合注册入口：24 家平台一站直达 |
常见问题（FAQ）
Q：检测显示 20 毫秒，网页为什么要三秒才出来？
A：20 毫秒是到某台机器的一次往返，网页要跑完解析、建连、握手才拿到第一个字节，再取几十个资源。中间任何一段绕路，都不会体现在这个延迟数字上。
Q：换了出口城市，图片还是慢，是不是线路不行？
A：先看 remote_ip 有没有变。remote_ip 还在原来的城市、解析结果也在原地，说明是调度没跟着走，不是线路的问题。两个地址都在新城市，才轮到查线路和带宽。
Q：怎么知道 CDN 给我的是哪个节点？
A：curl 的 remote_ip 是实际连上的机器，dig 的结果是调度返回的地址，两者一致就说明没有中间改写。响应头里的 via、x-cache 有时会带上节点代号，能进一步确认。
Q：改成远端解析是不是就一劳永逸？
A：不是。远端解析把解析质量交给了代理那一侧，对方 DNS 慢的时候，慢的是解析这一跳；另外本地还有 DNS 缓存，换完没清会继续用旧答案。它是把错位换成另一个可能性，不是消除代价。
Q：国内站和海外站要分开处理吗？
A：要。国内站多为 DNS 调度，解析地必须跟着出口；海外大站多数是 anycast，换出口自动就近，过度折腾解析反而可能拿到不该给的节点。同一套配置两头都用，通常有一头是白费。
Q：业务只调接口、不打开页面，还要管这些吗？
A：不必。接口返回一个 JSON，没有几十个静态资源，也不吃 CDN 缓存命中率。这类业务该盯的是成功率、并发和出口稳定性，绕路最多多一个往返。
📚 相关阅读
📄 代理IP出口乱跳：不是线路不稳，是路由表里有几条默认路由
更多帮助
如需获取更多帮助，请访问官网：socks5ip.com.cn
🛠️ IP综合检测中心：IP质量/线路/测速/业务模拟免费测
📝 官方注册入口：https://linkdd.cn/socks5ip（24 家平台自助开通，注册后按提示填邀请码）
💬 微信：17720135827 — 7×24h在线
全网低价IP｜聚合24家代理IP平台，全部免费测试，先测后买零风险
