4K/8K 极限下载速度排行榜：从 TCP 重传抓包到 IEPL 专线调优的实战排障手册

上周三晚上 21:40，一个做影视后期调色的朋友把一段终端输出甩到我微信上，说他新买的「500Mbps 大带宽」机场，播 YouTube 8K HDR 每隔 40 秒必缓冲一次，问我是不是他家宽带不行。我看了一眼他贴的 curl 结果：

$ curl -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total} speed:%{speed_download}\n' \
  --max-time 60 'https://speed.cloudflare.com/__down?bytes=500000000'
dns:0.012 connect:0.187 ttfb:1.842 total:60.001 speed:8333333
curl: (28) Operation timed out after 60001 milliseconds with 500000000 bytes received

speed:8333333 单位是 bytes/s，换算下来单流只有 8.3MB/s ≈ 66Mbps，而且 60 秒超时（cURL 28）。500MB 的文件下了 60 秒还没下完，说明单流吞吐被死死摁在 66Mbps 左右。8K HDR 的码率峰值能到 100~120Mbps，单流 66Mbps 当然周期性缓冲。

这就是我今天要拆的核心命题：「高速机场排行」这件事，宣传页上的 Mbps 数字和你能不能流畅播 8K，是两码事。我用 Wireshark 抓了他当晚的包，配合 mtr 和 tcpdump，一层层把根因挖出来，顺手把修复方案和防复发策略整理成这篇。中途会给出完整的 Sing-box 配置、sysctl 参数、iptables 规则，以及 16 家专线的实测天梯判断逻辑。

一、先复现故障：从 cURL 28 到 TCP SYN 重传的完整证据链

1.1 报错报文长什么样

朋友的环境是 Windows 11 23H2 + Clash Verge（Meta 内核），我让他先在 PowerShell 里跑一遍基础连通性，再用 WSL2 里的 curl 复测。Windows 原生 curl.exe 和 WSL2 的 curl 行为差异很大，这点后面单独讲。

PS C:\> curl.exe -v --max-time 15 "https://www.youtube.com/generate_204"
*   Trying 142.250.x.x:443...
* Connected to www.youtube.com (142.250.x.x) port 443
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* Recv failure: Connection was reset
* Closing connection
curl: (56) Recv failure: Connection was reset

注意这里是 curl: (56) 连接被重置，而不是 28 超时。56 通常意味着 TLS 握手阶段被中间设备 RST，可能是 SNI 被识别，也可能是本地代理没接管。切到 WSL2 再测：

$ curl -v --max-time 15 "https://www.youtube.com/generate_204"
*   Trying 142.250.x.x:443...
* Connected to www.youtube.com (142.250.x.x) port 443 (#0)
* TLS 1.3 connection using TLS_AES_128_GCM_SHA256
< HTTP/2 204
< content-length: 0

WSL2 通了，Windows 原生不通。第一层结论：Clash Verge 的 TUN 模式没接管 Windows 原生 curl 的流量，或者系统代理没生效。这是 Windows 上极常见的暗坑——TUN 模式和系统代理是两套机制，很多用户以为开了 TUN 就万事大吉，结果某些程序（尤其是走 WinHTTP 或硬编码直连的）绕过了代理。

1.2 Wireshark 抓包：SYN 重传暴露了什么

我让他在 WSL2 里对 YouTube 的 IP 做 tcpdump，同时用 curl 拉一个 8K 测试流。抓包过滤 tcp.flags.syn==1 or tcp.analysis.retransmission，结果如下（Wireshark 视图简化）：

No.  Time      Source          Destination     Protocol  Info
1    0.000000  192.168.1.23    104.18.x.x      TCP       49152 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256
2    1.001203  192.168.1.23    104.18.x.x      TCP       [TCP Retransmission] 49152 → 443 [SYN] Seq=0
3    3.003410  192.168.1.23    104.18.x.x      TCP       [TCP Retransmission] 49152 → 443 [SYN] Seq=0
4    7.007812  192.168.1.23    104.18.x.x      TCP       [TCP Retransmission] 49152 → 443 [SYN] Seq=0

四次 SYN，间隔 1s、2s、4s 指数退避，目标端一个 SYN-ACK 都没回。这是典型的 SYN 重传（SYN Retransmission），意味着三次握手根本没完成。但注意：WSL2 里 curl 是通的，为什么这里不通？因为这条抓包是在直连状态下抓的——他当时为了对比，临时关了代理。直连 YouTube 的 IP 被墙，SYN 自然无响应。

真正有价值的是开代理后的抓包。开 Clash Verge 后重新抓，过滤 tcp.analysis.retransmission or tcp.analysis.duplicate_ack：

No.  Time      Source          Destination     Protocol  Info
12   5.120341  10.0.0.1        198.51.x.x      TCP       51234 → 443 [ACK] Seq=1 Ack=1 Win=65535 Len=1360
13   5.121002  10.0.0.1        198.51.x.x      TCP       [TCP Dup ACK 12#1] 51234 → 443 [ACK] Seq=1 Ack=1
14   5.122110  10.0.0.1        198.51.x.x      TCP       [TCP Dup ACK 12#2] 51234 → 443 [ACK] Seq=1 Ack=1
15   5.350221  10.0.0.1        198.51.x.x      TCP       [TCP Retransmission] 51234 → 443 [ACK] Seq=1 Len=1360
16   5.351002  10.0.0.1        198.51.x.x      TCP       [TCP Dup ACK 12#3] 51234 → 443 [ACK] Seq=1 Ack=1

Dup ACK 连续三次 + Retransmission，这是链路丢包的教科书特征。接收端反复 ACK 同一个 Seq，说明中间某个包丢了，发送端超时重传。丢包位置需要 mtr 来定位。

1.3 物理链路拓扑还原

把整条链路画出来，后面所有分析都基于这张图：

[用户 Win11 23H2]
      │  (1) 家宽 PPPoE, MTU 1492
      ▼
[光猫/路由器 NAT]
      │  (2) 本地运营商 163 骨干
      ▼
[省网出口] ──(3)── [国际出口 GZ/SH]  ← 晚高峰拥塞点
      │  (4) 公网中转/或 IEPL 内网
      ▼
[境外入口节点] ──(5)── [落地出口 IP]
      │  (6) 回程到目标 CDN
      ▼
[YouTube / Netflix CDN 边缘]

丢包可能发生在 (2)(3)(4)(6) 任意一段。朋友的抓包显示 Dup ACK 出现在代理隧道建立之后，说明是 (4) 或 (6) 段的问题。mtr 一跑就清楚了。

二、mtr 逐跳定位：丢包到底发生在哪一跳

2.1 对公网中转与专线分别做 mtr

$ mtr -rwzc 200 --report-wide 198.51.x.x
Start: 2026-10-15T21:42:11+0800
HOST: home-pc                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   200    0.4   0.5   0.3   2.1   0.2
  2.|-- 100.64.0.1                 0.0%   200    3.2   3.8   2.9  12.4   1.1
  3.|-- 10.20.x.x                  0.0%   200    6.1   6.8   5.9  18.2   1.9
  4.|-- 202.97.x.x                 0.5%   200    8.4   9.1   7.8  22.1   2.3
  5.|-- 202.97.x.x                 3.5%   200   12.1  14.2  11.9  45.3   5.8
  6.|-- 202.97.x.x                12.0%   200   28.4  31.7  27.9  88.2  11.4
  7.|-- 198.51.x.x                12.0%   200   31.2  33.5  30.1  92.1  10.9

第 6 跳丢包 12%，第 7 跳（落地）也是 12%，说明丢包从第 6 跳开始且持续到终点——国际出口拥塞。这是公网中转的典型晚高峰表现。

再对一家全 IEPL 专线做同样测试（光速云的落地 IP）：

$ mtr -rwzc 200 --report-wide 203.0.113.x
Start: 2026-10-15T21:45:33+0800
HOST: home-pc                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   200    0.4   0.5   0.3   1.9   0.2
  2.|-- 100.64.0.1                 0.0%   200    3.1   3.6   2.8  10.2   0.9
  3.|-- 10.20.x.x                  0.0%   200    6.0   6.5   5.8  15.1   1.4
  4.|-- 10.88.x.x                  0.0%   200    7.2   7.8   7.0  16.3   1.6
  5.|-- 10.99.x.x                  0.0%   200   18.4  19.1  18.2  28.4   1.8
  6.|-- 203.0.113.x                0.0%   200   19.2  20.1  19.0  31.2   2.1

全程 0 丢包，且第 4、5 跳是 10.x 私有地址段——这是 IEPL 内网专线的铁证。公网路由不会出现 10.x 段。这一条判据，比任何宣传文案都硬。

2.2 关键判据表

现象	可能根因	验证命令	结论
SYN 重传，无 SYN-ACK	端口/IP 被封、本地防火墙拦截	tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0'	换节点或检查防火墙
Dup ACK + Data Retransmission	链路丢包	mtr -rwzc 200	看丢包起始跳
丢包在出境第一跳	本地运营商 QoS	对比不同运营商 SIM	换运营商或走专线
丢包在中间海缆段	国际出口拥塞	晚高峰 vs 凌晨对比	换 IEPL 专线
丢包在落地前	服务商回程问题	多节点对比	换服务商
小包通大包不通	MTU 黑洞	ping -M do -s 1472	调 tun MTU
单流低但多流高	单流 QoS 限速	curl 单流 vs iperf3 -P 16	换不限单流的服务商

三、MTU 黑洞：最容易被忽略的隐形杀手

3.1 现象与探测

朋友家是 PPPoE 拨号，MTU 天生就是 1492 而不是 1500。如果 tun 接口 MTU 设成 1500，大包会被静默丢弃——网页能开（小包），视频卡死（大包分片），SSH 能连但 scp 传文件中途断。这是 4K/8K 场景下最阴险的坑，因为它不报错，只是慢。

探测路径 MTU：

# Linux / WSL2
$ ping -M do -s 1472 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1492

$ ping -M do -s 1464 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.
1464 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms

-s 1472 对应总长 1500（1472+28），报 mtu=1492 说明路径 MTU 是 1492。-s 1464（1464+28=1492）通，确认无误。

Windows 上命令不同：

PS C:\> ping -f -l 1472 8.8.8.8
Ping 请求找不到主机...  # 或 "需要拆分数据包但是设置 DF"
PS C:\> ping -f -l 1464 8.8.8.8
来自 8.8.8.8 的回复: 字节=1464 时间=13ms TTL=117

3.2 修复：tun MTU 设为路径 MTU 减 28

Sing-box 的 tun 入站配置里，mtu 要设成路径 MTU 减去隧道封装开销。对于 PPPoE 1492 的家宽，tun MTU 设 1400 是保守稳妥值（覆盖绝大多数场景），激进一点可以设 1420。

{
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "singtun0",
      "address": ["172.19.0.1/30"],
      "mtu": 1400,
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true,
      "sniff_override_destination": false
    }
  ]
}

stack: system 用系统协议栈，性能比 gvisor 好但兼容性略差；gvisor 是用户态协议栈，兼容性好但吞吐略低。4K/8K 追求吞吐，优先 system。如果遇到某些 App 不兼容再回退 gvisor。

四、拥塞控制：BBR 为什么能把吞吐拉起来

4.1 cubic vs bbr 在高丢包链路的差异

TCP 默认拥塞控制是 cubic，它把丢包当作拥塞信号，一旦丢包就砍窗口。国际链路晚高峰丢包 5%12%，cubic 会把窗口砍到很小，单流吞吐断崖。BBR 基于带宽和 RTT 建模，不把丢包当拥塞，在高丢包链路下吞吐能提升 25 倍。

查看当前算法：

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic bbr

切到 BBR：

$ sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
$ sudo sysctl -w net.core.default_qdisc=fq
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr

注意：这是改本地内核的拥塞算法，影响的是本地到代理入口这一段。真正决定国际段吞吐的是落地服务器的拥塞算法，用户改不了，只能选服务商。但本地 BBR 对本地到入口段仍有帮助，尤其是本地到中转节点 RTT 较高时。

4.2 生产级 sysctl 调优

把下面这段写进 /etc/sysctl.d/99-network-tuning.conf，sysctl --system 生效：

# 拥塞控制
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 缓冲区（4K/8K 大吞吐场景适当放大）
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

# 连接队列
net.core.somaxconn = 32768
net.ipv4.tcp_max_syn_backlog = 16384

# TIME_WAIT 回收（高频短连接场景）
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 262144

# MTU 探测
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_base_mss = 1024

# 快速打开
net.ipv4.tcp_fastopen = 3

tcp_mtu_probing=1 是关键——它让内核自动探测路径 MTU，遇到 MTU 黑洞时自动降 MSS，避免大包被丢。这一条能救很多 PPPoE 用户的命。

五、Sing-box 完整配置：4K/8K 拉流专用

下面这份配置是给「单流吞吐优先、兼顾流媒体解锁」场景调的，直接可复用。注意 multiplex 部分——mux 能减少握手开销，但部分流媒体 CDN 对 mux 敏感，会误判为异常流量导致限速，所以对视频域名单独走非 mux 出站。

{
  "log": {
    "level": "info",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "remote",
        "address": "https://1.1.1.1/dns-query",
        "detour": "proxy"
      },
      {
        "tag": "local",
        "address": "223.5.5.5",
        "detour": "direct"
      }
    ],
    "rules": [
      {
        "domain_suffix": ["youtube.com", "googlevideo.com", "netflix.com", "nflxvideo.net"],
        "server": "remote"
      },
      {
        "domain_suffix": ["cn"],
        "server": "local"
      }
    ],
    "final": "remote",
    "strategy": "prefer_ipv4"
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "singtun0",
      "address": ["172.19.0.1/30"],
      "mtu": 1400,
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true,
      "sniff_override_destination": false
    }
  ],
  "outbounds": [
    {
      "type": "vless",
      "tag": "proxy",
      "server": "your-iepl-entry.example.com",
      "server_port": 443,
      "uuid": "00000000-0000-0000-0000-000000000000",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "your-iepl-entry.example.com",
        "utls": {
          "enabled": true,
          "fingerprint": "chrome"
        }
      },
      "multiplex": {
        "enabled": true,
        "protocol": "h2mux",
        "max_connections": 4,
        "min_streams": 4,
        "padding": true
      }
    },
    {
      "type": "vless",
      "tag": "proxy-video",
      "server": "your-iepl-entry.example.com",
      "server_port": 443,
      "uuid": "00000000-0000-0000-0000-000000000000",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "your-iepl-entry.example.com",
        "utls": {
          "enabled": true,
          "fingerprint": "chrome"
        }
      },
      "multiplex": {
        "enabled": false
      }
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    }
  ],
  "route": {
    "rules": [
      {
        "domain_suffix": ["googlevideo.com", "nflxvideo.net", "ytimg.com"],
        "outbound": "proxy-video"
      },
      {
        "domain_suffix": ["youtube.com", "netflix.com", "disneyplus.com"],
        "outbound": "proxy-video"
      },
      {
        "geoip": ["cn"],
        "outbound": "direct"
      },
      {
        "geosite": ["category-ads-all"],
        "outbound": "block"
      }
    ],
    "final": "proxy",
    "auto_detect_interface": true
  },
  "experimental": {
    "cache_file": {
      "enabled": true,
      "path": "cache.db"
    },
    "clash_api": {
      "external_controller": "127.0.0.1:9090"
    }
  }
}

关键点解释：

• proxy-video 出站关掉 mux，专供视频 CDN，避免 mux 被 CDN 误判限速；
• proxy 出站开 mux，供普通网页/API 用，减少握手开销；
• tcp_mtu_probing 配合 tun MTU 1400 双保险；
• DNS 分流，视频域名走远程 DoH，避免 DNS 污染导致拉到错误 CDN。

六、Clash Verge（Meta 内核）配置要点

Windows 用户大多用 Clash Verge，这里给一份精简但完整的 YAML：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict
global-client-fingerprint: chrome

profile:
  store-selected: true
  store-fake-ip: true

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true
  mtu: 1400

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - tls://1.0.0.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

proxies:
  - name: "IEPL-Video"
    type: vless
    server: your-iepl-entry.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: your-iepl-entry.example.com
    client-fingerprint: chrome
    smux:
      enabled: false

  - name: "IEPL-General"
    type: vless
    server: your-iepl-entry.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: your-iepl-entry.example.com
    client-fingerprint: chrome
    smux:
      enabled: true
      protocol: h2mux
      max-connections: 4
      min-streams: 4
      padding: true

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "IEPL-General"
      - "IEPL-Video"
      - DIRECT

  - name: "VIDEO"
    type: select
    proxies:
      - "IEPL-Video"
      - "I