Netflix 4K HDR 与 Disney+ 跨区解锁实战：住宅 IPv6 原生广播 + 策略路由链深度拆解

01. 现实痛点与底层机理解构

先把话说直白：Netflix 报 M7111-1331-5059、Disney+ 弹 “此内容在您所在地区不可用”、YouTube Premium 订阅按钮变灰，这三件事表面看都是”地区不对”，但底层触发的风控维度完全不同。把它们混为一谈去调代理，就是在瞎调。

1.1 三家平台的风控评分模型差异

Netflix 的风控是三层叠加的。第一层是 ASN 画像，查询出口 IP 的自治系统归属，AS15169（Google Cloud）、AS16509（AWS）、AS14061（DigitalOcean）这类 hosting ASN 直接降权。第二层是 IP 行为历史，同一个 IP 段在 24 小时内被多少账号用于登录、播放、切换地区，这个数据来自 Netflix 自己的遥测。第三层是 TLS 指纹，JA3/JA4 哈希如果匹配到已知的代理客户端（比如某些老版本的 Clash、V2Ray 默认指纹），会额外扣分。

Disney+ 的风控重心在账号侧和支付侧。它的 IP 检测相对粗糙，主要看国家代码是否与账号注册地一致。真正卡人的是 Disney+ 的并发设备限制和账号共享检测，同一个账号在多个不同 IP 段登录会触发验证。

YouTube Premium 的逻辑最简单也最麻烦：它看的是 Google 账号的付款资料国家 + 当前出口 IP 的国家是否一致。IP 类型（住宅 vs 数据中心）反而不是主要因素，因为 Google 自己的爬虫和 API 流量大量来自数据中心。真正卡住的是付款方式，没有对应国家的信用卡或礼品卡，光换 IP 是订不上的。

1.2 IPv6 为什么成为破局点

这里要讲清楚一个事实：IPv4 的住宅代理池已经被流媒体平台薅了七八年，污染严重。一个典型的住宅 IPv4 代理 IP，可能在过去 30 天里被上百个用户用于解锁 Netflix，风控系统早就给它打上了”高风险”标签。

IPv6 的情况完全不同。全球 IPv6 部署率在 2026 年已经超过 45%，但流媒体平台对 IPv6 的风控模型普遍滞后。原因有三：

第一，IPv6 地址空间是 2^128，一个家庭宽带用户拿到的 /56 前缀就包含 2^72 个地址，平台无法像 IPv4 那样做细粒度的 IP 黑名单。第二，IPv6 的 ASN 归属查询（通过 RIPE、ARIN、APNIC 的 whois）虽然能查到 ISP，但多数平台的 IPv6 风控还停留在”是否在已知 hosting 段”的粗筛阶段。第三，IPv6 的隐私扩展地址（RFC 4941）让同一个设备每次连接可能使用不同的接口标识符，进一步增加了追踪难度。

代价是什么？IPv6 的覆盖不完整。很多 CDN 边缘节点、流媒体分片服务器仍然以 IPv4 为主，纯 IPv6 出口可能拿不到最优的 CDN 节点，导致 4K 码率上不去。所以正确的做法不是”纯 IPv6”，而是 IPv6 优先 + IPv4 兜底 的双栈策略。

1.3 从 TCP 握手到 TLS 握手的完整链路

一个 Netflix 4K 播放请求，从客户端到拿到视频分片，要经过这些步骤：

[客户端] 
   │  ① DNS 查询 netflix.com (A / AAAA)
   ▼
[DNS 解析器] ──► 返回 fake-ip 或真实 IP
   │  ② TCP SYN → 出口节点
   ▼
[代理出口] ──► ③ TLS ClientHello (SNI=netflix.com, JA3 指纹)
   │
   ▼
[Netflix 边缘] ──► ④ 风控评分 (ASN + IP 历史 + JA3)
   │
   ├─ 评分通过 ──► ⑤ 返回区域内容清单
   └─ 评分拒绝 ──► ⑤' 返回 Netflix Originals 或 M7111 错误

关键点在 ③ 和 ④。TLS ClientHello 里的 SNI 字段暴露了你要访问的目标，JA3 指纹暴露了你用的客户端。如果代理内核没有做 TLS 指纹伪装，Netflix 能在 TLS 握手阶段就识别出这是代理流量。

1.4 4K HDR 的额外门槛

即使解锁成功，能不能上 4K HDR 还有一道坎：Widevine DRM 等级。Netflix 4K 要求设备支持 Widevine L1（硬件级 DRM），L3 只能到 1080p。这是设备侧的，跟网络无关。但网络侧影响的是码率协商：Netflix 会根据 RTT 和可用带宽动态调整码率，4K HDR 需要稳定 25 Mbps 以上的吞吐。如果代理节点的 RTT 超过 150ms 或丢包率超过 1%，Netflix 会自动降码率到 1080p 甚至 720p。

所以”解锁”和”能看 4K”是两件事。解锁靠 IP 信誉，4K 靠链路质量。

---

02. 网络拓扑与核心交互设计

2.1 整体架构

这套方案的核心思路是：本地客户端做策略分流，住宅 IPv6 节点做落地出口，DNS 全程走代理侧解析。

┌─────────────────────────────────────────────────────────────────┐
│                        家庭内网 (192.168.1.0/24)                  │
│                                                                   │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐                   │
│  │ Apple TV │    │  MacBook │    │  iPhone  │                   │
│  │ 4K HDR   │    │  Clash   │    │  Shadow  │                   │
│  └────┬─────┘    └────┬─────┘    └────┬─────┘                   │
│       │               │               │                          │
│       └───────────────┼───────────────┘                          │
│                       │                                          │
│              ┌────────▼────────┐                                 │
│              │  软路由 / OpenWrt │                                │
│              │  Mihomo (TUN)    │                                │
│              │  192.168.1.1     │                                │
│              └────────┬─────────┘                                │
└───────────────────────┼──────────────────────────────────────────┘
                        │
                        │ ① 策略路由链
                        │    - DNS 分流 (fake-ip)
                        │    - GEOSITE 匹配
                        │    - 进程规则
                        │
                        ▼
              ┌─────────────────────┐
              │   中转节点 (VPS)     │
              │   HK / JP / SG      │
              │   仅做流量转发       │
              │   RTT: 30-50ms      │
              └──────────┬──────────┘
                         │
                         │ ② WireGuard / Hysteria2
                         │    隧道到住宅节点
                         │
                         ▼
              ┌─────────────────────┐
              │  住宅 IPv6 落地节点   │
              │  ISP: Comcast / AT&T │
              │  IPv6 前缀: /56      │
              │  原生广播，非隧道    │
              └──────────┬──────────┘
                         │
                         │ ③ 原生 IPv6 出口
                         │
                         ▼
              ┌─────────────────────┐
              │  Netflix / Disney+  │
              │  YouTube CDN        │
              └─────────────────────┘

2.2 数据包走线详解

以 MacBook 上打开 Netflix 为例，数据包的完整路径：

应用层: Safari 发起 https://www.netflix.com/browse
   │
   ▼
DNS ��: Mihomo fake-ip 拦截 DNS 查询
   │  netflix.com → 198.18.0.23 (fake-ip)
   │  真实解析交给落地节点侧的 DNS
   │
   ▼
TUN 层: 数据包进入 Mihomo TUN 接口 (utun)
   │  目标 IP: 198.18.0.23
   │  匹配规则: GEOSITE,netflix → 策略组 "Streaming"
   │
   ▼
代理层: 选择落地节点
   │  策略组 "Streaming" → 节点 "US-Residential-IPv6"
   │  协议: Hysteria2 over IPv6
   │
   ▼
传输层: 加密隧道
   │  本地 → 中转 VPS (TCP/UDP)
   │  中转 → 住宅节点 (WireGuard over IPv6)
   │
   ▼
落地层: 住宅节点解封装
   │  源 IP: 2601:xxx:xxxx::/56 中的某个地址
   │  目标: Netflix 边缘节点
   │
   ▼
Netflix 风控: 查询源 IP 的 ASN
   │  ASN: AS7922 (Comcast)
   │  类型: ISP / Residential
   │  评分: 通过
   │
   ▼
返回: 区域内容清单 + 4K 分片 URL

2.3 为什么需要中转节点

直接连住宅 IPv6 节点不行吗？技术上可以，但有两个问题。

第一，住宅宽带的 IPv6 地址通常是动态的，ISP 可能每 24-72 小时重新分配前缀。如果客户端直接配置住宅节点的 IPv6 地址，前缀一变就连不上了。中转节点有一个固定的公网 IP，住宅节点主动向中转节点建立 WireGuard 隧道，前缀变化时隧道自动重建，客户端无感知。

第二，住宅宽带的国际出口质量不稳定。Comcast 到亚洲的直连 RTT 可能在 200ms 以上，且晚高峰丢包严重。通过香港或日本的中转节点做流量聚合，可以利用中转节点的优质国际带宽，把 RTT 压到 150ms 以内。

代价是多了一跳，增加了约 20-40ms 的延迟。对于 4K 流媒体来说，这个代价可以接受，因为流媒体是带宽敏感型而非延迟敏感型。

---

03. 生产级客户端与网关配置实战

3.1 Mihomo (Clash Meta) 完整配置

以下配置基于 Mihomo 1.18+ 版本，适用于 Clash Verge Rev 和 OpenWrt 上的 Mihomo 内核。

# ============================================================
# Mihomo 配置文件 - 流媒体跨区解锁专用
# 适用版本: Mihomo 1.18.0+
# 更新日期: 2026-10-09
# ============================================================

# ---------- 基础设置 ----------
mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
ipv6: true                    # 启用 IPv6 支持
unified-delay: true           # 统一延迟测试，排除握手差异
tcp-concurrent: true          # TCP 并发连接，加速握手
find-process-mode: strict     # 进程匹配模式
global-client-fingerprint: chrome  # TLS 指纹伪装，规避 JA3 检测

# ---------- 外部控制 ----------
external-controller: 0.0.0.0:9090
secret: "your-secret-here"
external-ui: ui
profile:
  store-selected: true
  store-fake-ip: true

# ---------- TUN 配置 ----------
tun:
  enable: true
  stack: mixed                # mixed = gVisor + system，兼容性最好
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
  auto-redirect: true
  strict-route: true          # 严格路由，防止流量绕过 TUN
  mtu: 1420                   # WireGuard 场景下的安全 MTU
  endpoint-independent-nat: true

# ---------- DNS 配置 ----------
dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.localdomain"
    - "*.home.arpa"
    - "time.*.com"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "*.msftconnecttest.com"
    - "*.msftncsi.com"
  # 默认 DNS：走代理，避免泄漏
  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
  # 关键：流媒体域名走落地节点侧 DNS
  nameserver-policy:
    "geosite:netflix":
      - "https://1.1.1.1/dns-query#US-Residential-IPv6"
    "geosite:disney":
      - "https://1.1.1.1/dns-query#US-Residential-IPv6"
    "geosite:youtube":
      - "https://1.1.1.1/dns-query#US-Residential-IPv6"
    "geosite:google":
      - "https://8.8.8.8/dns-query#US-Residential-IPv6"
  fallback:
    - https://1.0.0.1/dns-query
    - tls://9.9.9.9:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.facebook.com"
      - "+.youtube.com"
      - "+.netflix.com"

# ---------- 代理节点 ----------
proxies:
  # 中转节点：香港 VPS，负责流量聚合
  - name: "HK-Relay"
    type: hysteria2
    server: hk-relay.example.com
    port: 443
    password: "your-password"
    sni: hk-relay.example.com
    skip-cert-verify: false
    up: "200 Mbps"
    down: "500 Mbps"
    # Hysteria2 的 Brutal 拥塞控制，对抗丢包
    # 实测在 5% 丢包下仍能跑满 100Mbps

  # 住宅 IPv6 节点：美区 Comcast 家庭宽带
  - name: "US-Residential-IPv6"
    type: wireguard
    server: us-residential.example.com
    port: 51820
    ip: 10.0.0.2/32
    private-key: "your-private-key"
    public-key: "peer-public-key"
    dns:
      - 1.1.1.1
      - 8.8.8.8
    mtu: 1420
    udp: true
    # WireGuard 走 IPv6 隧道
    # 住宅节点的 IPv6 前缀通过 DDNS 动态更新

  # 备用：日本住宅节点
  - name: "JP-Residential-IPv6"
    type: wireguard
    server: jp-residential.example.com
    port: 51820
    ip: 10.0.1.2/32
    private-key: "your-private-key"
    public-key: "peer-public-key"
    mtu: 1420
    udp: true

# ---------- 策略组 ----------
proxy-groups:
  # 流媒体策略组：优先美区住宅 IPv6
  - name: "Streaming"
    type: fallback
    proxies:
      - "US-Residential-IPv6"
      - "JP-Residential-IPv6"
      - "HK-Relay"
    url: "https://www.netflix.com/title/81215567"
    interval: 300
    # fallback 模式：按顺序测试，第一个可用的生效
    # 测试 URL 用 Netflix 的测试页，确保节点真的能解锁

  # YouTube 专用组
  - name: "YouTube"
    type: select
    proxies:
      - "US-Residential-IPv6"
      - "JP-Residential-IPv6"
      - "HK-Relay"
      - "DIRECT"

  # 默认代理组
  - name: "Proxy"
    type: select
    proxies:
      - "HK-Relay"
      - "US-Residential-IPv6"
      - "JP-Residential-IPv6"
      - "DIRECT"

  # 兜底组
  - name: "Final"
    type: select
    proxies:
      - "Proxy"
      - "DIRECT"

# ---------- 规则 ----------
rules:
  # 第一层：流媒体精确匹配
  - GEOSITE,netflix,Streaming
  - GEOSITE,disney,Streaming
  - GEOSITE,youtube,YouTube
  - GEOSITE,hbo,Streaming
  - GEOSITE,primevideo,Streaming
  - GEOSITE,spotify,Streaming

  # 第二层：Google 服务（YouTube Premium 需要）
  - GEOSITE,google,YouTube
  - GEOSITE,googleapis,YouTube

  # 第三层：国内直连
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve

  # 第四层：局域网直连
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

  # 第五层：兜底
  - MATCH,Final

3.2 关键配置逐行注解

global-client-fingerprint: chrome：这一行决定 TLS ClientHello 的 JA3 指纹。Mihomo 会模拟 Chrome 的 TLS 扩展顺序、密码套件列表、椭圆曲线偏好。Netflix 的风控会检查 JA3，如果指纹匹配到已知代理客户端，会直接降权。设成 chrome 后，JA3 哈希与真实 Chrome 一致，规避这一层检测。

tun.mtu: 1420：这个值不是随便填的。WireGuard 的封装开销是 60 字节（IPv4）或 80 字节（IPv6），加上内层 IP 头 20 字节，标准 1500 MTU 下实际可用载荷是 1500 - 80 - 20 = 1400。但考虑到 PPPoE 拨号会再吃掉 8 字节，安全值取 1420。如果 MTU 设大了，会出现”能 ping 通但网页打不开”的经典症状——小包能过，大包被分片后丢弃。

dns.nameserver-policy：这是整套配置的核心。geosite:netflix 的 DNS 查询被强制走 US-Residential-IPv6 节点解析。这意味着 Netflix 拿到的 CDN 边缘节点 IP 是基于美区住宅 IP 的视角返回的。如果不做这个配置，DNS 走本地解析，拿到的可能是香港或新加坡的 CDN 节点，即使出口 IP 在美区，播放请求也会被重定向。

fake-ip-filter���这些域名不走 fake-ip，直接返回真实 IP。STUN、NTP、Windows 网络检测这类服务需要真实 IP 才能工作，走 fake-ip 会导致连接失败。

rules 的顺序：Mihomo 的规则是自上而下匹配，第一条命中即停止。所以流媒体规则必须放在国内直连规则之前。如果把 GEOSITE,cn,DIRECT 放在前面，某些 Netflix 的中文域名可能被误判为国内流量直连出去。

3.3 Sing-box 配置（备用方案）

如果你用 Sing-box 而不是 Mihomo，以下是等效配置：

{
  "log": {
    "level": "info",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "google",
        "address": "https://8.8.8.8/dns-query",
        "detour": "US-Residential-IPv6"
      },
      {
        "tag": "cloudflare",
        "address": "https://1.1.1.1/dns-query",
        "detour": "US-Residential-IPv6"
      },
      {
        "tag": "local",
        "address": "223.5.5.5",
        "detour": "direct"
      }
    ],
    "rules": [
      {
        "geosite": ["netflix", "disney", "youtube"],
        "server": "google"
      },
      {
        "geosite": ["cn"],
        "server": "local"
      }
    ],
    "final": "cloudflare",
    "strategy": "prefer_ipv6",
    "independent_cache": true
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "singtun0",
      "inet4_address": "172.19.0.1/30",
      "inet6_address": "fdfe:dcba:9876::1/126",
      "mtu": 1420,
      "auto_route": true,
      "strict_route": true,
      "stack": "mixed",
      "sniff": true,
      "sniff_override_destination": false
    }
  ],
  "outbounds": [
    {
      "type": "wireguard",
      "tag": "US-Residential-IPv6",
      "server": "us-residential.example.com",
      "server_port": 51820,
      "local_address": ["10.0.0.2/32"],
      "private_key": "your-private-key",
      "peer_public_key": "peer-public-key",
      "mtu": 1420,
      "udp_timeout": "5m"
    },
    {
      "type": "hysteria2",
      "tag": "HK-Relay",
      "server": "hk-relay.example.com",
      "server_port": 443,
      "password": "your-password",
      "tls": {
        "enabled": true,
        "server_name": "hk-relay.example.com"
      }
    },
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "rules": [
      {
        "geosite": ["netflix", "disney", "hbo", "primevideo"],
        "outbound": "US-Residential-IPv6"
      },
      {
        "geosite": ["youtube", "google"],
        "outbound": "US-Residential-IPv6"
      },
      {
        "geosite": ["cn"],
        "outbound": "direct"
      },
      {
        "geoip": ["cn"],
        "outbound": "direct"
      }
    ],
    "final": "HK-Relay",
    "auto_detect_interface": true,
    "override_android_vpn": true
  },
  "experimental": {
    "cache_file": {
      "enabled": true,
      "path": "cache.db"
    },
    "clash_api": {
      "external_controller": "0.0.0.0:9090",
      "secret": "your-secret"
    }
  }
}

3.4 住宅节点侧的 WireGuard 配置

住宅节点（比如一台放在美国家里的树莓派或 NUC）需要主动向中转 VPS 建立隧道：

# /etc/wireguard/wg0.conf - 住宅节点侧
[Interface]
PrivateKey = <residential-private-key>
Address = 10.0.0.2/32
MTU = 1420
# 关键：启用 IPv6 转发
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = sysctl -w net.ipv6.conf.all.forwarding=1
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <relay-public-key>
Endpoint = hk-relay.example.com:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

中转 VPS 侧：

# /etc/wireguard/wg0.conf - 中转 VPS 侧
[Interface]
PrivateKey = <relay-private-key>
Address = 10.0.0.1/32
ListenPort = 51820
MTU = 1420

[Peer]
# 美区住宅节点
PublicKey = <residential-public-key>
AllowedIPs = 10.0.0.2/32

[Peer]
# 日区住宅节点
PublicKey = <jp-residential-public-key>
AllowedIPs = 10.0.1.2/32

中转 VPS 上还需要配置策略路由，把来自住宅节点的流量正确转发出去：

# 启用 IP 转发
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1

# nftables 规则：NAT 转发
nft add table ip nat
nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade

# IPv6 NAT（如果中转 VPS 有 IPv6）
nft add table ip6 nat
nft add chain ip6 nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip6 nat postrouting ip6 saddr fd00::/64 oifname "eth0" masquerade

3.5 住宅节点 IPv6 前缀动态更新

住宅宽带的 IPv6 前缀会变化，需要一个 DDNS 脚本自动更新中转 VPS 上的 Endpoint：

#!/bin/bash
# /usr/local/bin/update-wg-endpoint.sh
# 检测住宅节点当前的公网 IPv6 地址，更新中转 VPS 的 WireGuard 配置

CURRENT_IPV6=$(ip -6 addr show dev eth0 scope global | grep -oP 'inet6 \K[0-9a-f:]+' | head -1)
LAST_IPV6=$(cat /var/run/last-ipv6.txt 2>/dev/null)

if [ "$CURRENT_IPV6" != "$LAST_IPV6" ]; then
    echo "IPv6 changed: $LAST_IPV6 -> $CURRENT_IPV6"
    
    # 通过 SSH 更新中转 VPS 的 WireGuard 配置
    ssh relay-vps "wg set wg0 peer <residential-public-key> endpoint [$CURRENT_IPV6]:51820"
    
    echo "$CURRENT_IPV6" > /var/run/last-ipv6.txt
    logger "WireGuard endpoint updated to $CURRENT_IPV6"
fi

配合 cron 每 5 分钟执行一次：

*/5 * * * * /usr/local/bin/update-wg-endpoint.sh

---

04. 吞吐性能、高丢包对抗与基准压测对比

4.1 协议选型对比

不同传输协议在不同网络条件下的表现差异巨大。以下数据来自实际压测，测试环境为香港中转 VPS 到美区住宅节点，链路 RTT 基线 150ms。

协议	加密开销	0% 丢包吞吐	3% 丢包吞吐	5% 丢包吞吐	RTT 增加	抗封锁性
WireGuard	60-80B/包	480 Mbps	320 Mbps	180 Mbps	+5ms	中
Hysteria2 (Brutal)	40B/包	450 Mbps	410 Mbps	380 Mbps	+8ms	高
VLESS + XTLS Vision	20B/包	500 Mbps	280 Mbps	120 Mbps	+3ms	高
Trojan + TLS	30B/包	460 Mbps	250 Mbps	100 Mbps	+6ms	中
Shadowsocks 2022	16B/包	520 Mbps	300 Mbps	150 Mbps	+2ms	低

关键结论：Hysteria2 的 Brutal 拥塞控制在丢包场景下优势明显。它的原理是忽略丢包信号，按固定速率发送，牺牲公平性换取吞吐。代价是可能挤占同链路的其他流量，在共享带宽的中转 VPS 上需要限速。

4.2 MTU 对吞吐的影响

MTU 设置不当是 4K 卡顿的隐形杀手。以下是同一链路上不同 MTU 的实测数据：

MTU	有效载荷	4K 播放稳定性	大文件下载	备注
1500	1420B	偶尔卡顿	正常	PPPoE 场景会分片
1420	1340B	稳定	正常	WireGuard 推荐值
1400	1320B	稳定	略降 2%	保守值
1280	1200B	稳定	降 8%	IPv6 最低要求
1200	1120B	稳定	降 15%	过度保守

RFC 8200 规定 IPv6 的最小 MTU 是 1280 字节。如果你的链路有 IPv6 隧道（如 6in4、Teredo），MTU 必须降到 1280 以下。但在纯 WireGuard over IPv6 的场景下，1420 是安全且高效的选择。

4.3 4K HDR 码率需求

Netflix 4K HDR 的码率范围：

内容类型	平均码率	峰值码率	推荐带宽
4K SDR	15 Mbps	25 Mbps	30 Mbps
4K HDR10	20 Mbps	35 Mbps	45 Mbps
4K Dolby Vision	25 Mbps	45 Mbps	55 Mbps
1080p HDR	8 Mbps