延迟、抖动与丢包各自影响什么
玩家说「卡」，往往混着三件不同的事。延迟是数据包从设备到游戏服务器再返回的时间，以毫秒计，决定操作与反馈之间的间隔；抖动是延迟的波动幅度，决定这个间隔稳不稳；丢包是数据包在链路上没有到达，决定操作在服务端算不算数。
三者的体感差别很大。延迟偏高但稳定，是可以适应的：你会自然提前半拍，重新形成肌肉记忆。抖动则很难适应，同一套连招有时判定成立、有时落空，节奏永远对不上。丢包的破坏最直接——位置回弹、技能无效、明明躲开却被判定命中，这些通常不是帧数问题，而是状态同步没跟上。
还有一个容易忽略的区别：下载和看视频走 TCP，丢包会被重传补上，你只觉得慢一点；实时对战多走 UDP，不重传，丢一个包就是一次状态不同步。所以「测速够快」和「游戏不卡」是两件事，带宽数字帮不上忙。
| 指标 | 游戏里的感受 | 常见成因 | 先查什么 |
|---|---|---|---|
| 延迟 | 操作慢半拍，但节奏稳定 | 物理距离远、路由绕行 | 到目标服务器的往返路径 |
| 抖动 | 同一套操作时快时慢，难以形成肌肉记忆 | 链路拥塞、无线干扰、共享带宽 | 本地网络与晚高峰时段 |
| 丢包 | 位置回弹、技能无效、瞬移 | 链路拥塞、UDP 被限速、无线丢帧 | 线路类型与 UDP 转发是否正常 |
延迟与丢包随运营商、时段、目标服务器变化，任何固定数字都没有参考价值。有意义的是方法与顺序：先测出问题在哪一段，再决定用不用加速。测的时候用持续 ping 观察五到十分钟的延迟分布与丢包计数，不要只看一次结果。
加速器与全局代理的工作方式差在哪
全局代理把设备上的所有流量交给同一个出口，配置简单，适合网页浏览与跨区访问。代价是游戏流量和系统更新、语音、下载挤在同一条链路上，任何一项占满带宽，游戏就跟着抖。
游戏加速器一般只接管指定进程或指定规则的流量，其余直连；同时对游戏常用的 UDP 做针对性转发，并按目标服务器挑选线路。一句话概括：代理解决「能不能到达」，加速解决「到达得稳不稳」。
| 对比项 | 直连 | 全局代理 | 游戏加速器 |
|---|---|---|---|
| 接管范围 | 无 | 设备全部流量 | 按规则或按进程 |
| UDP 支持 | 原生 | 取决于协议与客户端实现 | 通常显式支持 |
| 链路选择 | 运营商默认路由 | 固定单一出口 | 按目标服务器选线路 |
| 对下载与视频的影响 | 无 | 共用同一条链路 | 基本不占用 |
| 适用场景 | 本地服务器、单机 | 网页与跨区访问 | 海外服对战与联机 |
协议看承载方式，不看名字
订阅链接里常见的 Shadowsocks、VMess、Trojan、VLESS 都以 TCP 承载为主，再通过各自的方式承载 UDP；Hysteria2 与 TUIC 基于 QUIC，本身跑在 UDP 上，在丢包较多的链路上更有优势，但对网络环境也更敏感。选择顺序建议是：先确认客户端支持，再看链路是否稳定，最后才比较峰值速度。
分流规则与 DNS 泄漏
分流规则决定哪些域名或 IP 走线路、哪些直连。规则没有覆盖到游戏的登录与对战域名，就会出现「客户端显示已连接、延迟却一点没变」。DNS 泄漏是另一个常见问题：解析请求仍由本地运营商处理，结果是连上了线路，却匹配到不合适的区域，延迟没有改善甚至更差。
不少客户端默认只代理 TCP。游戏走 UDP，如果 UDP 没有被接管，界面看起来是连上的，实际对局仍走本地网络。先确认 UDP 转发或 TUN 模式是否开启，再谈线路选择。
海外服延迟高的原因，按这个顺序排查
先说结论：换线路能解决的是绕行与拥塞，解决不了物理距离与服务端状态。把这两类分开，排查会快很多。
物理距离决定延迟下限。数据在光纤里以接近光速传播，跨洲往返本身就有固定耗时，任何软件都抹不掉这段距离。加速能做的是让路径更直、更少排队，而不是把距离变短。
- 先排除本地因素：优先有线连接；无线环境注意信道占用与干扰；暂停后台更新与同步；路由器长时间运行后重启一次。
- 再看时间规律：只在晚高峰变差，通常是国际段共享链路拥塞；全天都差，更可能是路由绕行，或目标服务器本身距离过远。
- 看路径而不是只看结果：用系统自带工具或第三方工具观察每一跳的延迟变化，判断问题出在本地出口、国际段还是目标端。
- 最后才怀疑服务端：官方维护、排队、区域服务器负载，这类问题换任何线路都一样。
线路类型：直连、中转与 IEPL 专线
直连是数据从本地直接到目标，路径由运营商决定，成本最低，但国际段在高峰时段容易与其他流量争抢。
中转是先接入一个中转节点，再从中转节点到目标。它绕开的往往是拥塞最严重的几跳，实际效果取决于中转节点的带宽、位置与承载的流量规模。
IEPL 专线属于企业级专线，链路相对固定，不与其他公共流量争抢，稳定性更高，成本也更高，通常用在固定时段、对稳定性敏感的场景。
按使用频率选即可：偶尔联机，中转类线路够用；固定时间打排位，优先专线类线路。判断线路好坏不要只看一次测速，观察晚高峰时段的延迟与丢包变化更有参考价值。
线路是否真的可用，可以用几个可验证的数字核对：覆盖范围、线路数量与退款窗口。以 VPNCZ 为例，线路列表里可以查到 120+ 国家与 180+ 线路，退款窗口为 30 天。
哪些场景值得用，哪些用了也没用
把场景分清楚，能省掉很多无效折腾。
- ✅ 海外服对战与联机合作，且延迟或抖动在晚高峰明显变差
- ✅ 游戏走 UDP，而当前网络对 UDP 限速或不稳定
- ✅ 需要固定出口：与朋友同区、参加固定时间的活动
- ✅ 多设备共用网络，下载与游戏互相挤占，需要把游戏流量单独接管
- ❌ 单机游戏与本地服务器对局：流量本来就没有出境
- ❌ 官方维护、排队或全区故障：线路改变不了服务端状态
- ❌ 本地无线环境差、路由器老化：先修本地，再谈线路
- ❌ 账号封禁与地区限制：这是账号与规则问题，不是网络问题
- ❌ 本地服务器已经低延迟：多一层转发只会多一个环节
判断标准不是游戏类型，而是问题发生在哪一段：出在出境之后的国际段，加速才有意义；出在本地或服务端，加速只是在中间多绕一层。
客户端、订阅链接与分流规则
订阅链接导入是最常见的接入方式：一条链接里包含节点、协议与部分分流规则，客户端按周期更新节点列表。需要注意，订阅链接等同于账号凭据，泄露等于把线路交给别人使用——不要转发，不要贴到公开场合，发现异常时在面板里重置。账号层面，VPNCZ 的注册只需要用户名与密码，无需邮箱地址。
平台差异
- Windows 与 macOS：桌面客户端通常支持进程级分流与 TUN 模式，可以把单个游戏进程单独接管。
- iOS 与 Android：移动端受系统限制，以规则分流为主；在 Wi-Fi 与移动网络之间切换后，要确认连接是否仍然生效。
- Linux：多以内核或命令行客户端为主，配置更接近手写规则，分流规则需要自己维护。
导入之后先核对三件事
- 游戏进程或对应规则是否已被覆盖，而不是一把梭的全局模式。
- UDP 转发是否开启，当前协议与客户端是否支持游戏所需的承载方式。
- DNS 解析是否走线路，出口地区是否与目标服务器所在区域一致。
出口 IP、DNS 解析与进程接管三项都正确，剩下的差异基本来自线路本身；其中任何一项不对，先修配置，换线路不会有帮助。
现象对照：先处理哪一个
把常见现象与更可能的原因对起来，可以少走弯路。
| 现象 | 更可能的原因 | 先做什么 |
|---|---|---|
| 延迟稳定但整体偏高 | 物理距离远或路由绕行 | 核对出口位置，换线路类型 |
| 延迟忽高忽低 | 链路拥塞或无线干扰 | 改有线、避开高峰、记录时段规律 |
| 画面回弹、技能无效 | 丢包，UDP 未走线路或被限速 | 确认 UDP 转发与进程接管 |
| 只有某一个游戏有问题 | 分流规则未覆盖该游戏 | 补规则，或改为按进程接管 |
| 显示已连接但延迟没变化 | 流量没有走线路 | 核对出口 IP 与 DNS 解析 |
最后一行最值得留意：客户端显示已连接、延迟却没有任何变化，多半是流量根本没有走线路，属于规则或 DNS 问题，换线路不会有帮助。