内网穿透变慢别瞎猜，10分钟揪出真正卡点

一句话：内网穿透延迟高、速度慢，十有八九是流量被中转节点绕了远路，或者上行带宽到顶了，不是穿透本身的开销。用 tracert 和 ping 十分钟测出真正卡在哪一类，再对症选直连还是加宽。

场景与痛点

东西是跑起来的。frp 也好，某个免费内网穿透服务也好，配置文件改对了，服务能连上，指示灯是绿的。问题出在跑起来之后——远程桌面拖影、传个文件几百 KB/s 就封顶、游戏一卡一卡，你甚至开始怀疑是不是自己家宽带出了问题。

搜了一圈，得到的答案永远是那几句：网络不稳定、服务器性能不足、换个高带宽的公网、避开网络拥堵时段。这些话没有一句是错的，但也没有一句能让你现在就动手解决问题——它们说的是"可能"，不是"你的情况具体是哪一种"。

内网穿透延迟高、内网穿透速度慢，真正缺的不是"再换一个软件试试运气"，而是一件很朴素的事：一个能让你亲眼看见流量到底走了哪条路的方法。看清楚之后，问题往往一眼就能定位。

你需要准备什么

项：两端设备（能开命令行/终端）；说明：Windows 用 cmd，macOS / Linux 用终端，跑 ping、tracert / traceroute

项：一个正在用的穿透方案；说明：frp、某个免费内网穿透服务，或者你现在用的任何方案——先测现状，别急着换

项：iperf3（可选）；说明：想精确区分"卡在带宽"还是"卡在绕路"再装，官网和各系统包管理器都有

项：5-10 分钟；说明：全套诊断动作不复杂，跑一遍数据基本就清楚了

先搞清楚有哪几种做法

流量从你这边到对方那边，说到底只有这么几条走法，先按"流量走哪条路"分个类，而不是按产品名字分类：

做法：中转转发（frp / 各家免费穿透服务）；谁在承担带宽成本：中转服务器的运营方（自建则是你自己）；慢在哪 / 难在哪：免费档通常限速；流量要先绕到中转节点所在的机房，节点离你越远、用的人越多，延迟和速率就越差；什么情况下选它：网络环境完全改不了（校园网、公司网），或者对延迟不敏感，比如偶尔传个文件

做法：公网 IP 直连（申请公网 IP + 端口映射）；谁在承担带宽成本：你自己的宽带；慢在哪 / 难在哪：多数家庭宽带申请不到公网 IP，要么加钱开专线，要么联系运营商，还要动路由器配置；什么情况下选它：已经有公网 IP、也懂基础网络配置

做法：P2P 打洞直连（虚拟局域网类工具）；谁在承担带宽成本：两端各自的宽带，不占用第三方；慢在哪 / 难在哪：没有公网 IP 也能打通；极端严苛的对称型 NAT 环境下，打洞有小概率失败；什么情况下选它：没有公网 IP、不想为带宽额外付费、想要接近物理链路的延迟

做法：混合型（打洞失败自动回落中转）；谁在承担带宽成本：平时用两端带宽，极端情况用中转兜底；慢在哪 / 难在哪：需要工具自己判断何时该回落，普通用户不用操心，但兜底那一小段时间体验会退化；什么情况下选它：想要"能直连就直连，连不上也不至于完全用不了"的保底方案

中转转发的优点要如实说：它成功率最高，什么网络环境都能用，校园网、公司网这类你完全管不了出口的场景，中转往往是唯一能用的选择。

这篇走的路线是：先诊断你现在具体卡在哪一类，再决定要不要换、往哪个方向换——而不是一上来就告诉你换掉现在的方案。

第一步：先破除一个误解——穿透本身几乎不耗时间

很多人下意识觉得"用了内网穿透就是比直连慢"，把锅甩给了封装和加密。这个锅背得冤——加密和封装带来的开销是微秒级的，跟"绕路"造成的毫秒到百毫秒级延迟，中间差了三个数量级，几乎可以忽略。

真正拖慢速度的，是像 frp 这类中转转发工具的工作原理：你和对方各自主动连上一台公网服务器（中转节点），你的数据包先跑到这台中转节点，再由它转发给对方——中转节点在哪，很大程度上决定了你的延迟。如果两端本来就在同一座城市，直接访问的物理延迟通常能压到 1 毫秒以内；但只要中转节点不在本地、甚至架在外省（比如你在杭州，中转节点却在青岛甚至更远），距离动辄上百公里起步，延迟直接从 1 毫秒的量级跳到四五十毫秒起——这还只是物理距离这一笔账，都还没算上中转节点本身处理、排队的时间。

下面这张图是同一段路程的两种走法：

同城直接访问延迟通常在1毫秒以内，经外省中转节点转发要先绕到异地机房再折返，延迟跳到40-50毫秒起

延迟之外还有另一笔账：带宽。中转节点的出口带宽是固定的、大家一起分的——免费穿透服务通常挂着一批用户共用同一台机器，自建 frp 如果图便宜，也大概率是一台配置有限的云主机。这台机器此刻正在服务多少人、有没有人正拉着大文件下载或者在做备份，直接决定了此刻能分给你的那一份还剩多少。你没有变慢，是同一根上行被更多人一起抢了。

机器上没什么人时带宽基本都留给你；很多人挂在同一台中转机器上、尤其有人在下大文件时，能分给你的带宽被明显挤占

✅ 读完这一步能回答：慢不是因为"用了穿透"，是"绕了远路"（延迟）和"被别人挤占了带宽"（速率）两笔账，得分开看。

第二步：测出你的流量实际走了哪条路

Windows 打开 cmd，输入 tracert 对方的地址；macOS / Linux 打开终端，输入 traceroute 对方的地址。跑完你会看到一串编号的跳数，每一跳是路径上的一个路由节点，后面跟着它的往返延迟。

怎么读这串结果：

• 正常的同城或跨省直连，跳数通常不多，且延迟随距离平缓增长

• 如果中间某一跳延迟突然陡增，且之后所有跳的延迟都叠加在这个数值附近，这一跳大概率就是绕出去的中转节点

• 可以用 IP 归属地查询工具反查这一跳的大致地理位置——如果它出现在一个跟你和对方都不沾边的城市，基本可以确认走了中转

延迟量级可以作为大致参考：同城或相邻城市的光纤物理延迟通常在个位数到十几毫秒；跨省大约每百公里增加 1ms 左右（具体因运营商骨干网路由而异，仅供大致判断，不必当成精确公式）。如果你测出来的 RTT 远超过两地实际距离该有的量级，那多半是绕远了。

配合 ping -n 100（Windows）或 ping -c 100（macOS / Linux）多跑几十次，观察延迟的波动幅度——波动比平均值更能说明"是不是时快时慢"这类问题。

✅ 确认标志：你能说出自己的流量经过了哪几跳、最大的一跳延迟出现在哪个位置。

第三步：把"慢"归到三类原因里

跑完前两步，对照下表把自己的情况归类：

类型：① 中转绕路；特征：tracert 某一跳延迟陡增，之后各跳延迟叠加不下降；反查这一跳归属地，跟你和对方所在城市都对不上；对应解法：换一条不用绕远路的方案：自己申请公网 IP 直连，或者换成 P2P 打洞类工具，让流量不再经过第三方

类型：② 上行带宽打满；特征：RTT 本身不算离谱，但传输速率长期卡在某个固定值，这个值接近你或对方的宽带上行带宽上限；对应解法：升级上行带宽，或者换成不额外占用第三方带宽的直连方案——这类瓶颈是你自己的物理链路上限，换哪种软件都绕不过去

类型：③ 打洞失败回落中转；特征：表现时快时慢，重新连接后延迟不一样，有时候直连总建不起来、只能走中转兜底；对应解法：先检查两端的网络环境（NAT 类型）是不是偏严苛；网络确实改不动，配合强化穿透能力的工具再试一次直连

如果你归到了 ① 或 ③——流量被迫绕远、或者打洞总失败退回中转——这两类问题本质上是同一件事：数据没能走两端之间最短的物理路径。

这正是虚拟局域网 / SDN 类直连工具想解决的问题。以 MoleSDN 为例：两端设备各自装上客户端，绑进同一个服务域，系统会优先尝试在两端之间直接打通一条 P2P 连接——不经过任何第三方中转，两端之间实际能跑多快，取决于你和对方各自的宽带上行带宽，而不是某台公用服务器的性能和排队人数。

Windows 客户端已接入服务域，显示分配到的虚拟 IP 与延迟看板

真正打不通的极端网络环境（比如校园网、严苛的对称型 NAT），才会退回去走一次中转兜底，这时也有超级鼹鼠这类强化穿透的手段可以先试一次直连。跟"换一台高配服务器做中转"比起来，直连是从根上不绕路，而不是把要绕的这条路修得更宽一点。

这不是说中转方案不能用——校园网、企业内网这类你完全管不了出口的环境下，中转仍然是唯一能用的选择，参见前面的方案对比表。它只是在"两端都有基本上网条件"这个更常见的场景里，不必是那个必须多绕一圈的选项。

✅ 确认标志：你知道自己该往哪个方向走了——换直连方案，还是升级带宽，还是两者都要。

第四步：换路之后，自己怎么验证有没有效

换完别急着下结论，用第二步同一套命令再测一次，对比这三件事：

1. tracert 的跳数是不是变少了，中间那个身份不明的中转节点是不是消失了

2. RTT 的绝对值是不是回到了"两地物理距离该有的量级"

3. 如果之前是 ③ 打洞失败回落中转的情况，反复断开重连几次，延迟是不是稳定了，不再时快时慢

三条都对上了，说明流量真的走了直连；只对上一两条，回头看看是不是还卡在 ②——带宽上限本身就在那，换哪种直连方案都提不上去，这时候该升级的是带宽，不是软件。

✅ 确认标志：tracert 里那个身份不明的中转跳数消失，RTT 落回合理区间。

连通效果实测

这篇没有直接甩一组"我们测出来是多少毫秒"的数据——你和对方所在的城市、运营商、宽带套餐都跟任何示例环境不一样，抄一组别人的数字对你没有参考意义，编的数字比没有还糟糕。真正有用的是第二步和第四步的对比方法：换路前后各测一次，自己的数字自己说了算。

想更细一点的话，把 iperf3 用上：两端各起一次单流测试，跟你们各自宽带上行的理论值做个对比，就能分清"卡在带宽"还是"卡在绕路"——这两类问题的解法完全不同，别混在一起判断。

常见问题

应用侧

问题 1：iperf3 测出来吞吐很快，但实际用起来还是卡

iperf3 测的是持续吞吐量，游戏、远程桌面这类场景对延迟和抖动更敏感，吞吐够不代表延迟稳定。回头看多次 ping 的波动幅度（最大值和最小值差多少）——抖动大比平均延迟高更影响体验；如果你的情况属于 ③ 打洞失败回落中转，时快时慢正是抖动的来源。

问题 2：Windows 上 tracert 全是星号（*）

中间的路由器或防火墙没有回应 ICMP 探测包，这在很多运营商骨干网和云服务商都很常见，不代表这一跳真的丢包或不可达。星号跳过去看后面能不能继续，只要最终能到达目标，中间几跳星号可以先不管。

网络侧

问题 3：换成直连方案，两端总是打不通

至少一端的 NAT 类型比较严苛（比如对称型 NAT），打洞成功率低，常见于校园网、公司网、部分双运营商家宽。先测出自己是哪一类再决定怎么改，参考对称型 NAT 排查那篇。

问题 4：时快时慢，重连之后表现还不一样

大概率是第三步里的 ③ 打洞失败回落中转——两端有时候能打通直连，有时候打不通只能退回中转，表现自然不稳定。多断开重连几次观察规律；如果确认经常打不通，直接按问题 3 的思路处理网络环境，或者用强化穿透的手段兜底。

进阶与扩展

如果两端之间不止一条物理链路可选——比如你家是双线宽带、或者对端所在网络有多个出口——直连方案怎么知道该走哪条？

MoleSDN 的智能选路功能提供两种策略：延迟优先和带宽优先，登录控制台进对应服务域的设置，在「高级功能」里开启后，客户端里点一下就能切换：

MoleSDN 客户端智能选路弹窗，延迟优先与带宽优先两张卡片可一键切换

延迟优先会持续探测可用线路，挑当下往返时间最短的那条，适合游戏联机、远程桌面这类对卡顿敏感的场景；带宽优先则倾向选吞吐更高的线路，适合大文件传输、视频备份这类对峰值速率更敏感的场景。切换不用手动改路由，点一下卡片就生效。

智能选路「延迟优先」模式的动图演示

智能选路「带宽优先」模式的动图演示

总结

内网穿透延迟高、速度慢，十次里大半不是软件本身的锅——是流量绕了远路，或者上行带宽本来就到顶了。花十分钟跑一遍 tracert 和 ping，比换三个软件试运气有用得多。

如果诊断结果指向"绕远路"或者"打洞总失败"，直连类方案能从根上解决问题——两端之间实际能跑多快只取决于你们各自的带宽。参考快速上手，几分钟就能建好一个服务域试一下。

祝早点连上，也祝以后不用再怀疑是不是自己家网不好。

相关阅读

• 对称型 NAT 还有救吗 —— 如果第三步归到了"打洞失败回落中转"，这篇教你先测出自己是哪一类 NAT，再决定怎么改

• Windows 远程桌面调优 —— 卡的是远程桌面画面，直连解决的是链路，画面还有一层参数可以调

• OMV NAS 异地访问 —— 卡的是访问家里的 NAS，这篇是完整的 NAS 异地访问教程

• 电脑远程唤醒教程 —— 另一个"配好了却不生效"的经典问题，排查思路类似

• 两台电脑大文件互传 —— 卡的是传输大文件，这篇专门讲怎么传得快

更新记录

• 2026-09-09：首发