本文速览

适合已经能连接、但网页响应慢或下载速度不稳的用户。先用固定目标建立基线，再依次比较节点、接入网络、协议与本地设置。v2rayN 用显式代理请求核对流量入口，v2rayNG 用同一应用和同一网络重复测试；最终留下可复现的记录，而不是只凭一次延迟数值换节点。

先区分首屏慢、吞吐低与间歇断流

“网速慢”至少包含三种情况：点开网页后等很久才出现内容；页面能打开，但下载持续很慢；刚开始正常，过一会儿就停住。它们分别可能涉及解析与握手、可用带宽、连接稳定性。客户端显示的延迟通常只覆盖某一种探测过程，不能代替真实网页或持续下载测试。

先暂停系统更新、云盘上传和其他下载。在同一设备上选择一个日常访问的 HTTPS 页面，以及一个允许下载、大小足够维持测试的固定文件。不要同时更换节点、浏览器和测速目标，否则很难知道是哪项改动起了作用。

3 次
每组重复次数，比较中位结果
30 秒
每次持续下载的建议观察窗口
1 项
每轮只改变一个条件

这些数字是测试安排，不是本站实测成绩，也不是性能保证。短文件可能提前下载完，无法反映持续吞吐；流量套餐有限时，缩短观察窗口并让各组保持一致。下载工具中的 MB/s 与运营商的 Mbps 也不同，理想换算是 1 MB/s 等于 8 Mbps，实际还存在协议开销。

  • 首屏等待长：记录解析耗时、建立连接耗时与首字节耗时，留意是否只有首次打开慢。
  • 持续吞吐低：看稳定阶段的传输量，不把启动瞬间的峰值当结果。
  • 间歇断流：记录断流时间、屏幕是否关闭、网络是否切换，以及当时的内核日志。

第一层：比较节点负载与出口差异

节点名称里的地区不是完整线路说明。两个地区相同的节点，可能使用不同机房、入口与出口；两个名称不同的节点，也可能共享同一入口。订阅更新只是刷新配置，不会自动增加服务器带宽。先在相同网络、相近时间，用同一目标比较两个可用节点。

v2rayN 可以在服务器列表中选择节点，再用右键菜单里的速度测试功能初筛；菜单名称随版本变化。v2rayNG 先在主列表选中节点，重新建立连接，再回到同一个应用测试。内置测试的目标、并发数与实际访问未必相同，所以最终仍以真实业务复测为准。

对照现象更值得检查的方向下一步
只有一个节点持续慢该节点负载、限速或出口路径保留另一个节点作对照，换时段再测
多个节点在晚间一起变慢共享入口拥塞或本地运营商路径保持节点不变，比较另一接入网络
只有一个下载站慢目标站限流、出口互联或内容分发调度增加第二个独立目标，不急着改协议
内置测速快，浏览器下载慢测试目标不同或浏览器未走同一出站核对路由和代理入口，再比较同一文件

如果能管理服务端，再查看同一时间的 CPU、带宽占用与连接数；不能管理时，就把结论写成“疑似节点侧瓶颈”，不要仅凭客户端速度认定服务器超售。不同时间段的结果只能提供线索，不能替代同一条件下的对照。

判断：先固定一个可用对照节点

同一目标在节点 A 上反复慢、在节点 B 上反复正常时，先保留 B 恢复使用，再收集 A 的时间与日志。此时没有必要同时重设本地 DNS 和传输参数。

第二层：分开检查接入网络与跨网线路

保持节点与目标不变，把安卓手机从 Wi-Fi 切到移动数据后重新连接 v2rayNG，再做一组测试。切网会中断原有连接，旧页面的缓存与旧下载任务不能作为新网络结果。桌面端可以用手机热点对照，但要考虑热点本身的信号与套餐限制。

如果只有 Wi-Fi 慢，先靠近路由器，再比较 5 GHz 与 2.4 GHz 频段；距离远、隔墙多时，5 GHz 也未必更稳。若同一 Wi-Fi 下直连业务也慢，应先处理无线干扰、路由器负载或宽带上行占满，而不是不断调整代理内核。

  1. 用默认网关作本地链路探测目标，先检查设备到路由器这一段是否稳定。
  2. 在 Windows 运行 ping -n 30，后面填写实际网关地址；再按同样方式测试允许探测的节点地址。
  3. 比较有无持续丢包与明显抖动，同时运行真实 HTTPS 请求，避免只根据探测包下结论。
  4. 同一节点换网络后反复恢复正常，再把调查重点转向接入网络或运营商到入口的路径。

晚高峰变慢、凌晨恢复，通常值得观察拥塞因素，但也可能是目标站负载变化。请同时记录两个目标。不要仅凭一次测速决定修改 MTU；只有出现特定网络上握手成功、较大数据传输反复卡住等可复现现象时，再进一步调查路径 MTU 与隧道封装。

第三层：核对协议、传输方式与服务端参数

VMess、VLESS 是代理协议名称，TCP、WebSocket、gRPC 属于不同层面的传输选择，TLS 又承担安全传输功能。不能把这些名称混成一张速度排行榜。实际表现取决于服务器实现、网络路径、目标站与设备性能，协议名称本身不能保证吞吐。

v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；两者支持的字段与特性可能不同。v2rayN 的表现也取决于所选内核及其配置。更换客户端不是只搬运一个节点地址，还要确认该内核支持订阅下发的协议与传输组合。

  • 先核对节点：地址、端口、用户标识、TLS 开关应与服务端一致。端口为 443 并不自动代表已启用 TLS。
  • 再核对传输：WebSocket 的路径与 Host、gRPC 的服务名、TLS 的服务器名称等，应按服务端提供的参数填写。
  • 最后做对照：只有服务端确实提供另一组可用入口时，才比较传输方案；不要把现有节点的 WebSocket 直接改成 gRPC。
  • 保留原配置：导出后再改，出现连接失败立即回退。不要为了速度关闭证书验证。

多路复用也不是统一的加速开关。对许多短连接，它可能减少重复建立连接的成本；在某些丢包环境或长时间大流量任务中，多个请求共享底层连接又可能互相影响。若当前内核与协议支持该设置，用开、关两组数据比较，不要同时改并发数和传输方式。

判断：配置不匹配先修复，稳定性问题再调优

频繁出现握手失败、连接重置或路径错误时，先核对服务端参数。只有连接稳定、对照条件一致时，吞吐差异才适合用来评估传输方案。

第四层：验证本地代理、DNS 与分流设置

Windows 的系统代理不保证所有程序都会遵循。v2rayN 可从托盘菜单的「系统代理」选择自动配置系统代理，但终端仍可能直连；浏览器扩展也可能覆盖系统设置。先检查「设置」→「参数设置」中的本地监听设置。不同版本可能将其放在「基础设置」或入站相关页面，以实际显示为准。

下面用 Windows PowerShell 显式指定 HTTP 代理入口，排除“程序没有使用系统代理”这一变量。先把本地监听端口确认为 10809，再复制命令；若实际端口不同，先修改命令。这里的 10809 只是示例，不代表每个 v2rayN 安装环境的默认值。

curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} speed=%{speed_download}B/s\n" https://v2rayultra.com/

这条命令用于验证入口和观察请求阶段，不是持续吞吐测试。time_connect 在此主要反映到本地代理的连接，time_starttransfer 还包含后续隧道、握手与目标响应等待，不能直接叫作“节点延迟”。测试大文件时，改成自己有权访问的固定下载地址；达到 30 秒上限可能主动结束请求，不要把这种结束误判为节点掉线。

  • 检查路由：系统代理仅把流量送进内核，之后仍可能被分流到直连。通过访问日志核对测试目标的实际出站，不要把“全局接入”当成“所有目标都走代理”。
  • 检查 DNS：首次访问慢、重复访问快时，观察是否有解析超时；不要把所有 DNS 地址一次替换。安卓「私人 DNS」与客户端 DNS 设置要分开核对，分别改动并复测。
  • 检查安卓分应用设置：在 v2rayNG「设置」→「分应用代理」中确认测试应用是否被纳入代理。版本文案可能不同，还要看当前选择的是代理列表还是绕过列表。
  • 检查后台限制：在安卓系统「设置」→「应用」→「v2rayNG」→「电池」查看后台限制。若仅锁屏后断流，可临时允许后台运行验证，再权衡耗电。
  • 检查设备负载：桌面端看任务管理器，安卓端留意发热与降频。TUN 模式、其他 VPN 服务与代理工具不要同时反复切换，以免路由变化掩盖问题。

日志中的超时与重置怎样对应慢速

开启详细日志只用于短时间排查。先记下请求发生的时间，再找同一时段、同一目标的记录；单条报错可能只是后台应用请求失败。日志级别长期设得过细会增加存储与处理开销，排查结束后恢复日常级别。分享日志前隐藏订阅地址、用户标识与服务器信息。

报错：context deadline exceeded

原因：某个操作在期限内没有完成，可能出现在解析、拨号或其他请求阶段，单凭这一句不能认定服务器过载。

解法：读取前后文确认目标与阶段，保持节点不变换接入网络，再保持网络不变换节点，比较超时是否随条件移动。

报错：connection refused

原因：目标连接被主动拒绝；若地址是本地回环地址，常见于监听端口不正确或内核未启动。

解法：先分清拒绝的是本地入口还是远端服务。核对 v2rayN 监听端口、内核运行状态，远端拒绝则核对节点地址和服务端监听。

报错：connection reset by peer

原因：连接被对端或路径上的设备重置，既可能与服务端有关，也可能与网络设备或传输参数有关。

解法：记录重置发生在握手还是传输途中，核对 TLS 与传输参数，然后换网络复测；不要只凭这一句决定更换协议。

完整错误措辞可能随操作系统与内核版本变化。若日志始终没有对应请求，优先检查应用是否进入代理，而不是继续调整远端节点。若请求已走预期出站、传输却持续停顿，再把日志与前面的节点和网络对照记录放在一起分析。

常见问题与排查结束条件

延迟最低的节点，为什么下载反而更慢？

短请求延迟不等于可用带宽。保留同一文件与同一网络，各测 3 次，比较持续下载结果；同时确认测速请求和下载请求走的是同一节点、同一出站。

更新订阅后还是慢，要每天更新吗？

订阅更新只能同步提供方发布的配置。先确认当前节点仍有效，再按节点与网络两组对照定位；如果只有晚高峰慢，重复更新通常不会改变这段线路的拥塞。

打开 TUN 就能让所有软件更快吗？

TUN 主要改变流量接入方式，不会扩充服务器带宽。若普通代理已能覆盖测试应用，先保留原模式；只有应用未进入代理时，再按客户端说明验证 TUN 和路由设置。

v2rayNG 亮屏正常，锁屏后变慢怎么办？

先保持同一网络，比较亮屏与锁屏时的下载或请求记录。若只在后台异常，检查系统电池限制、后台数据权限和省电模式，不要先修改节点传输参数。

排查可以在找到稳定、可复现的差异后结束。记录“时间、接入网络、节点、目标、代理模式、三次结果、日志片段”即可；不必继续追求某个看起来更低的延迟数字。需要进一步求助时，这份记录比一句“所有节点都卡”更容易定位问题。

  1. 本地直连业务也慢：先处理接入网络与设备负载。
  2. 仅一个节点慢：保留可用节点，向服务提供方反馈对照记录。
  3. 换网络即恢复：重点检查无线链路、运营商路径与共享入口。
  4. 显式代理正常、应用异常：回到系统代理、分应用代理和路由规则。
  5. 只有特定传输配置失败：核对服务端参数及内核兼容性，再讨论性能。