workbuddy.xpcool.com/远程游戏串流方案_家到公司.md

# 家庭主机远程串流方案（公司电脑 → 家里主机）

> **目标**：在公司电脑上远程控制家里主机，能正常游玩《英雄联盟》快节奏娱乐模式（海克斯大乱斗类，团战密集、吃操作延迟）。
> **版本**：v5 | 2026-09-10 | **状态：公网 IPv4 申请被拒 → IPv6 路线重启评估。家里入口已就绪，瓶颈转移到「公司端没有 IPv6 出口」**

---

## v4 → v5 修订摘要（**IPv4 申请失败 → IPv6 路线重启**）

用户反馈：**打 10000 申请公网 IPv4 未成功**（运营商不给家宽公网 IPv4）。于是把 v4 判死的 IPv6 路线重新翻出来，逐项核对前置条件。

| 项 | v4 状态 | v5 实测/修订 |
|---|---|---|
| 公网 IPv4 | ✅ 主攻路线 | ❌ **申请被拒** —— 这条路暂时封死 |
| IPv6 直连 | ❌ "公司无 IPv6，判死" | ⚠️ **重启评估** —— 家里侧条件经复查**全部达标**，卡点收敛为一个非常具体的点：**公司端缺 IPv6 出口** |
| 家里 IPv6 出网 | 未单独测 | ✅ **19:00 复查全通**：`ipv6.icanhazip.com` / `www.taobao.com` / `www.qq.com` 的 TCP 443 全部 OK |
| 家里 IPv6 地址 | 只知道有两个随机地址 | ✅ **发现固定后缀地址** `...:29f1:e63f:d476:597e`（`Suffix=Link`，后缀**不轮换**）→ 适合做长期服务地址 + DDNS 目标 |
| 家里 IPv6 入站 | 未证明（手机测过一次失败） | ⏳ **待复测** —— 最大嫌疑是天翼网关**默认拦截 IPv6 入站**（IPv6 是"无 NAT 直通"，放行全靠网关防火墙） |
| 公司端 IPv6 出口 | 无（硬结论） | 🔑 **新增解法：手机 5G 热点** —— 用户手机实测**有 IPv6**（能开 `ipv6.icanhazip.com`），等于公司笔记本可以"借"一条 IPv6 出口 |

**v5 路线重排：**

| 优先 | 路线 | 画质上限 | 公司端代价 | 卡点 |
|---|---|---|---|---|
| **A（主攻）** | **手机 5G 热点 → 公司笔记本获得 IPv6 → 直连家里 IPv6** | **1080p120 满血** | 零安装 | ① 热点下游能否拿到 IPv6 ② 家里网关是否放行入站 |
| B | 腾讯云 frp 中继（公司 IPv4 → 服务器 → 家里） | 1080p60（受 5 Mbps 限） | 零安装 | 服务器 IPv6 支持 |
| C | 网易UU远程 / ToDesk | 中继延迟 + 反作弊风险 | 零安装 | 无 |

> **核心洞察**：v4 之后瓶颈从「**家里没有入口**」变成「**公司没有 IPv6 出口**」。
> 家里其实**有一条干净的入口**（公网 IPv6，无 NAT、只需网关放行），只是公司这侧够不着 —— 而"够不着"这件事，一部手机就能补上。

**方案 A 的两条硬约束（必须提前认清）**

| 约束 | 数值 | 说明 |
|---|---|---|
| **流量成本** | 1080p120 @ 20 Mbps ≈ **9 GB/小时** | 这才是手机热点的真正代价。打 3 小时 ≈ 27 GB，必须确认套餐余量或办一张大流量副卡 |
| **延迟代价** | 预计 **40–70 ms** | 5G 空口 + 跨网（手机运营商 → 电信）。LOL 可接受（普通玩家本身 30–50 ms），但**打不满 120fps 的体感优势** |

---

## v3 → v4 修订摘要（**路线第三次修正，这次是定案**）

公司端 `net-test-v2.ps1` 实测结果回来了（`net-test-v2_20260910_163314.txt`），**三条硬结论**：

| 项 | v3 假设 | v4 实测结论 |
|---|---|---|
| 公司出站端口 | 未知，担心是白名单 | ✅ **完全自由**：`portquiz.net` 的 `443/8080/8443` 全 OPEN，连你腾讯云的 **`22025`** 也 OPEN → **任意 TCP 端口出站都能用** |
| **公司 NAT 类型** | 未知 | ❌ **对称 NAT**（同一本地端口问不同 STUN → 映射端口 `16993/16994/17011` 各不相同）+ **多公网出口**（`117.188.24.89` 与 `117.188.118.254` 同时出现、按目的地分流）→ **P2P 打洞基本不可行** |
| 公司 IPv6 | v3 已判死 | ❌ 复核确认 `IPv6 local : NONE` |
| 公司管理员权限 | 未知 | ⚠️ 当前会话**非管理员**，但账号 `ybtdevxxl` **在 Administrators 组内** → 可提权（只需点一次 UAC） |
| 公司已装软件 | 未知 | 🎁 **已装 `Clash Verge`、`WireGuard`、`ToDesk`、火绒** —— 若将来走隧道，WireGuard 现成、无需再装驱动 |
| 公司安全软件 | 火绒在跑 | ⚠️ **火绒 `HipsDaemon` / `HRWSCCtrl` 运行中**；其余 EDR（`aTrust` / `edr_monitor` / `savsvc` / Defender 全系）**均为 Stopped** → 没有强制管控在跑，这是好消息 |
| 公司主屏 | 2560×1600@120 | ✅ 复核一致（脚本报 `1707×1067` 是 **150% 缩放后的逻辑值**，2560÷1.5 = 1707） |

**路线定案：**

| 路线 | 判决 | 依据 |
|---|---|---|
| IPv6 直连 | ❌ **死** | 公司无 IPv6 |
| Tailscale / ZeroTier **打洞** | ❌ **基本死** | 公司**对称 NAT + 多出口 IP**，映射端口不可预测 |
| **A. 申请公网 IPv4 + Sunshine 直连** | ✅ **主攻** | 公司出站任意端口均可用 → 拿到公网 IP 即可 **1080p120 满血** |
| B. 腾讯云 frp 中继 | ⚠️ 可立即启用，画质受限 | 公司能连腾讯云任意端口 → 技术上完全通；**但服务器仅 5 Mbps**，只够 1080p60 @ 4~5 Mbps |
| C. 网易UU远程 | ⚠️ 兜底 | 厂商大带宽中继、不受 NAT 影响、专为游戏优化；代价是反作弊风险 |
| D. ToDesk | ⚠️ 兜底 | 已实测可连通（走中转），办公向延迟 |

> **一句话总结**：唯一的瓶颈是**家里没有公网 IP**。解决它，一切迎刃而解；不解决，就只能接受「中继 + 降码率」。

---

## v2 → v3 修订摘要（**重要，路线变了**）

公司端自测结果回来后，发现 v2 的核心前提不成立，路线必须再改一次：

| 项 | v2 结论 | v3 修订 |
|---|---|---|
| 打通方式 | 公网 **IPv6 直连** | ❌ **作废**：公司网络**完全没有 IPv6**（本机无 IPv6 地址、IPv6 出网两条 DNS 全不通）→ IPv6 直连从"最优解"变成"走不通" |
| 家里 NAT 类型 | "对称 NAT，打洞困难" | ❌ **v2 测错了**：v2 每个 STUN 用新 socket（新本地端口），映射端口当然不同。**正确测法**（同一 socket 问多个 STUN）结论是 —— **端点无关映射（锥形/Cone NAT），打洞可行** ✅ |
| 公司端口白名单 | v1 报"443 不通、疑似白名单" | ❌ **v1 测错了**：拿 `114.114.114.114:8080`（该主机根本没开 8080）和 `github.com:443`（国内 DNS 被污染）当靶子。已重做为**有效靶子**测法（见 `net-test-v2.ps1`） |
| 首选路线 | IPv6 直连 | ✅ **改为二选一**：**A. 申请公网 IPv4 + 端口转发**（若电信批）／ **B. Tailscale 打洞**（家里是锥形 NAT，基础不错） |
| 公司屏幕 | 待补测 | ✅ **2560×1600 @ 120Hz** → 120Hz 屏是意外之喜，手感延迟少 8ms 左右 |
| 公司安全软件 | 未知 | ⚠️ 发现企业级管控：**火绒 HipsDaemon / HRWSCCtrl** + `edr_monitor` + `savsvc`（详见 1.6） |
| 画质定档 | 1080p120 | ✅ 维持 **1920×1080 @ 120fps**（公司屏 16:10，串流按 1920×1080 等比即可） |

---

## 一、实测底账（2026-09-10）

### 1.1 被控端（家 · 本机）硬件

| 项目 | 实测值 | 对串流的意义 |
|---|---|---|
| 显卡 | **NVIDIA RTX 4070 SUPER**（驱动 32.0.15.9186） | Ada 架构，NVENC 支持 **H.264 / H.265 / AV1** 硬编，画质天花板很高 |
| CPU | Ryzen 7 7800X3D（8C/16T） | 游戏性能强，编码走 NVENC 不占 CPU |
| 内存 | 31.2 GB | 充足 |
| 系统 | Windows 11 专业版 build 26200 | Sunshine / Moonlight 官方良好支持 |
| 显示器 | AOC **2560×1440 @ 170Hz** | 可输出 2K 高刷；但按 1080p120 定档更稳 |
| 网卡 | Realtek 2.5GbE，链路 1Gbps，IP `192.168.1.30` | 有线千兆，本地无瓶颈 |
| 网关 | `192.168.1.1`（可访问，LuCI 界面） | 见 1.4 |

### 1.2 网络实测 —— 三个决定性发现

| 指标 | 实测值 | 结论 |
|---|---|---|
| 下行 | 943.82 Mbps | 千兆宽带（Ookla，电信上海节点 id 3633） |
| **上行** | **46.36 Mbps** | **画质天花板；可撑 1080p120 甚至 2K120** |
| 丢包 | **0.0%** | 线路质量好 |
| 出口 IPv4 | `1.204.100.17`（电信，广东，动态） | ⚠️ 这是**运营商 NAT 的公网出口**，不是你家地址 |
| **tracert 第 2 跳** | **`100.64.0.1`** | ⚠️⚠️ **运营商级 NAT（CGNAT）实锤** |
| 出口 IPv6 | **`240e:338:263:3600::/64`** | ✅ **公网 IPv6，可被外部直达（待验证入站放行）** |
| STUN 映射端口 | ❗v2 报"每次不同"→ **测法有误**；**正确复测（同一 socket 打多个 STUN）**：本地端口 55001 → 恒为 `:3051`；55002 → 恒为 `:3063` | ✅ **端点无关映射（Cone/EIM）**，IPv4 侧打洞**可行**，不是对称 NAT |

**修正后的三条推论**

1. ❌ **IPv4 端口转发仍不可行** —— 你确实没有公网 IPv4（`100.64.0.1` 是运营商大内网，RFC 6598 专用段）
2. ✅ **IPv4 侧 P2P 打洞是可行的** —— 家里是**锥形 NAT（映射端点无关）**，这是打洞最有利的一类。v2 里"对称 NAT 打洞困难"的结论是**因为测试方法错误**（每问一个 STUN 就换一个新 socket → 本地端口变了，映射端口当然跟着变）。**已用正确方法复测推翻。**
3. ⚠️ **IPv6 虽然最优，但公司没有** —— 家里有公网 IPv6 这点仍然成立，只是**公司那条网线/WiFi 完全跑不了 IPv6**。
   🔄 **v5 修订（措辞必须精确）**：这不等于"IPv6 在公司场景作废"，而只是"**公司的那一条网络出口**没有 IPv6"。公司笔记本还有**第二条出口**从未被用上 —— **手机 5G 热点**（用户手机实测有 IPv6）。所以这条路在 v5 复活，详见第二章 A 案。

### 1.3 家里可直接对外服务的 IPv6 地址（**v5 · 19:00 复查更新**）

```
240e:338:263:3600:29f1:e63f:d476:597e   ← ✅ 首选：Suffix=Link，后缀固定不轮换，生命周期 1.21 天（自动续期）
240e:338:263:3600:e591:cb62:3503:8a23   ← ⚠️ Suffix=Random（隐私扩展地址），会轮换，当前 17.7 小时后过期
240e:338:263:3600:51f3:a026:4256:a337   ← ❌ Deprecated（已废弃，忽略）
```

**这次复查最大的收获：找到了一个"后缀永不变化"的地址。**

| 地址组成 | 是否变化 | 说明 |
|---|---|---|
| 前缀 `240e:338:263:3600::/64` | ⚠️ **可能变** | 天翼网关 PPPoE 拨号时下发，重拨或运营商侧调整时会变 |
| 后缀 `29f1:e63f:d476:597e` | ✅ **不变** | 基于网卡标识派生（`Suffix=Link`），网卡不换它就永远不变 |

**这带来一个很实际的好处**：DDNS 只需要盯住**前缀那 4 段**是否变化，Windows 侧什么都不用改（不必关隐私扩展），就能拿到一个长期可寻址的目标地址。

其他实测（19:00）：
- **IPv6 出网正常**：`ipv6.icanhazip.com` / `www.taobao.com` / `www.qq.com` 的 TCP 443 **全部 OK**
- IPv6 默认路由 → `fe80::1`（网关）
- Windows 防火墙：Public 档开启（家里以太网属 Public），且 `node.exe` 有 Public/Private **入站 Allow** 规则 → 本机侧不拦

> **v5 补充（路线重启）**：这组地址**重新变成核心资产**。v4 时因为"公司无 IPv6"把它判死，但公司那台笔记本还有一条**从未用上**的出口 —— **手机热点**（见第二章 A 案）。用户手机实测有 IPv6，等于随时能给公司笔记本接上一条 IPv6 通道。

⚠️ 前缀由网关 RA 下发，重拨可能变 → 长期使用必须配 DDNS（见第七章）。

> **⚠️ 仍待证明的一件事**：家里能**出** IPv6（已验证），但**外部能不能进得来**还没证明。IPv6 没有 NAT，"放行全靠网关防火墙"——天翼网关默认**拦截入站**，这是此前手机测试失败的最大嫌疑。验证方法见第七章。

---

### 1.4 网关（路由器）与密码找回

**判定结果**：**中国电信智能网关（天翼网关）**，管理界面为 LuCI 风格（首页 302 到 `/cgi-bin/luci`），网关 MAC `88-C7-8F-A6-BC-43`。

忘记后台密码的**阶梯式解决办法**（从省事到暴力）：

1. **看机身贴纸**：找 `useradmin` 和随机的 8 位密码。普通账号能看状态页与 WAN 信息，部分型号也能改端口映射 / IPv6 防火墙
2. **试超级管理员默认密码**：账号 `telecomadmin`，经典默认 `nE7jA%5m`（华为系天翼网关最常见），其次 `admintelecom`。部分地区出厂就是随机密码（贴在机身或在电信 App 里）
3. **手机 App**：`小翼管家` / `天翼看家`，可查看网关信息、部分设置，也常能重置管理密码
4. **打 10000 号**：报宽带账号，让客服重置网关管理密码
5. **恢复出厂**（reset 孔长按 10 秒）：**最后一招**。天翼网关重置后会经 TR-069 自动重新下发业务配置（含宽带账号），多数能自动恢复上网，但有失败风险，需客服兜底
6. ✅ **其实可以完全绕开路由器后台**：
   - **IPv6 直连不需要端口转发**（IPv6 无 NAT，只需网关防火墙放行入站）
   - **组网打洞不需要后台**（Tailscale / ZeroTier）
   - **商业远控不需要后台**（UU远程 / ToDesk 走它们自己的服务器）

> 结论：**拿不到路由器密码不会阻塞方案**。只有"网关把 IPv6 入站也拦了，且你不同意用打洞/中转"这一种情况才需要密码去放行。

### 1.5 本机环境的重要细节

- Windows 防火墙：Domain=开启 / **Private=关闭** / Public=开启；**以太网被判定为 Public 档**
- **当前会话不是管理员** → 装 Sunshine、加防火墙规则、改电源计划都需要你点一次 UAC 确认
- 已存在的远控残留驱动：`Todesk Virtual Display Adapter`、`GameViewer Virtual Display Adapter`（网易UU远程）、`MuMu Virtual Display Adapter`
- 本机装有 Clash Verge（系统代理 127.0.0.1:7897，当前开关=0）与火绒（HipsDaemon / HRWSCCtrl）

### 1.6 公司端（**v3 已拿到实测结果**）

来源：`网络自测结果_20260910_160152.txt`（公司电脑本地运行 v1 脚本产出）

| 项目 | 实测值 | 结论 |
|---|---|---|
| CPU | **AMD Ryzen 7 7840H**（8C/16T，Zen4） | 性能远超解码需求 |
| 核显 | **AMD Radeon 780M**（RDNA3 / Phoenix，VCN 4.0） | ✅ **支持 AV1 硬解**，也支持 H.265 |
| 内存 | 31.2 GB | 充足 |
| 系统 | Windows 11 专业版 build 26200 | 良好 |
| 屏幕 | **共享显示器 + 2560×1600@120Hz**（另有 `Sharing Monitor` 虚拟项） | ✅ **120Hz**！比 v2 假设的 60Hz 屏好一档，少约 8ms |
| **IPv6** | **本机无 IPv6 地址；IPv6 出网（阿里 v6 DNS / 电信 v6 DNS）全部不通** | ❌ **企业网是纯 IPv4** → 有线/WiFi 这条出口没有 IPv6（🔄 v5：可改用**手机热点**作为 IPv6 出口） |
| UDP 出网 | STUN 可用（`stun.miwifi.com`、`stun.hitv.com` 均有响应，本地高位端口 → 公网 `117.188.24.89`） | ✅ **高位 UDP 可出网且能收到回包**，这是打洞/串流的基础 |
| 系统代理 | 开关=0，但服务器填了 `127.0.0.1:7892` | ⚠️ 公司电脑上可能装过 Clash 类代理客户端（**待查是否在跑、有无可用节点**） |
| 安全/管控软件 | **`HipsDaemon`（火绒 HIPS 主服务）**、**`HRWSCCtrl`（火绒安全中心）**、`edr_monitor`、`savsvc`、`OneDrive×2` | ⚠️ **有企业级 HIPS/EDR**，装 VPN 驱动（TUN/虚拟网卡）大概率会弹窗告警甚至被拦；也可能记录外联行为 |
| 出站 TCP 端口自由度 | v1 结论**不可信**（靶子无效，见 v3 摘要） | 🔄 需用 `net-test-v2.ps1` 复测 |
| 管理员权限 | **待确认** | 决定能不能装 Tailscale（要装 TUN 驱动）；Moonlight 便携版不需要管理员 |

**补充实测（2026-09-10 16:28，用户提供 `ipconfig`）—— 接入方式与网络身份已确认**

```
无线局域网适配器 WLAN:
   IPv6 地址 . . . . . : fe80::ecdb:9605:2cf8:9a3d%11   <- 仅链路本地，无全局 IPv6
   IPv4 地址 . . . . . : 192.168.250.84
   子网掩码  . . . . . : 255.255.255.0
   默认网关. . . . . . : 192.168.250.1
```

| 项 | 结论 |
|---|---|
| 接入方式 | **笔记本 + WiFi 接入企业网**（不是有线） |
| 内网网段 | `192.168.250.0/24` —— 企业统一网段（家用极少见），网关 `192.168.250.1` |
| IPv6 | **只有 `fe80::` 链路本地地址，无 RA 全局地址** → 企业网本身不发 IPv6 | 🔄 **v5 精确化**：死的是"**这条企业网出口**"，不是"公司场景"。笔记本可另接**手机热点**获得 IPv6（见第二章 A 案） |
| 出口 IP | `117.188.24.89`（全公司共享同一出口，非公司专属） |
| 内网 IP 归属 | 由企业网 DHCP 下发，**随时可能变**，不能用作稳定地址 |

> **公司端唯一还缺两块拼图**：① 出站端口是否真被白名单限制；② 是否有管理员权限。两者都能用 `net-test-v2.ps1` 一次性拿到。

**从被控端（家里）反查 ToDesk —— 意外挖到一个好消息（2026-09-10 16:29）**

用户在公司用 ToDesk 控制家里主机，我直接在家里这侧抓了 ToDesk 的实时连接：

```
# ToDesk 全部对外 TCP（非局域网）
TCP Established  59695 -> 219.151.138.225:8080     <- 非标端口！
TCP Established  59665 -> 219.151.138.225:443
TCP Established  57577 -> 118.24.225.33:443

# 到公司出口 117.188.24.89 的直连：无记录
# ToDesk UDP 端点（家里侧，多个 IPv6 地址 + IPv4）
UDP 240e:338:263:3600:e591:cb62:3503:8a23:57068
UDP 240e:338:263:3600:51f3:a026:4256:a337:57067
UDP 240e:338:263:3600:29f1:e63f:d476:597e:57066
UDP 192.168.1.30:57069
```

两条关键推论：

1. ✅ **公司网络允许出站到非标端口（至少 8080 可用）** —— 这是**分量很重的利好**：说明公司不是"只放行 80/443"的白名单防火墙。若家里将来有公网 IPv4，Sunshine 的 `47989/47990/48010` 这些端口公司大概率能直连；腾讯云 frp 中继（任意端口）也具备可行性。
2. ⚠️ ToDesk **TCP 层没有与公司出口 IP 的直连**，且文件传输会话为 `planb:1 ... p2p:0`（走中转）。UDP 是无连接的、从端点列表看不到对端，所以**不能据此断定打洞失败**，但至少没有直连证据 → 打洞方案（路径 B）的信心下调。

> 附带发现：家里这台主机的 IPv6 地址有**多个轮换的隐私扩展地址**（同一前缀下 3 条）。这印证了"IPv6 直连必须配 DDNS"的判断（不过该路线已被公司端否决，仅留档）。

---

## 二、方案选型（v5 定案）

**先看硬约束 —— 它们决定一切：**

| 约束 | 事实 | 影响 |
|---|---|---|
| 家里无公网 IPv4 | CGNAT（tracert 第 2 跳 `100.64.0.1`），且 **10000 申请被拒** | ❌ 端口转发 / 直连彻底没戏（v5 确认这条路已走不通） |
| 家里 IPv4 NAT | **锥形 / 端点无关映射（EIM）** | 单看家里是打洞友好，但被下一条堵死 |
| **公司 NAT 类型** | ❌ **对称 NAT + 多公网出口**（同一本地端口映射到 `16993/16994/17011` 各不相同；出口 IP 出现 `117.188.24.89` 与 `117.188.118.254` 两个） | **对称 + 锥形 组合 → 打洞不可行** |
| **家里有公网 IPv6** | `240e:338:263:3600::/64`，**19:00 实测出网全通**，且找到**固定后缀地址** | ✅ **v5 主攻：这是家里唯一干净的入口** |
| 公司（有线/WiFi）无 IPv6 | `IPv6 local : NONE`（企业网不发 RA） | ⚠️ **但不是死路** —— 可借手机热点补出口 |
| **手机 5G 有 IPv6** | 用户手机实测可打开 `ipv6.icanhazip.com` | ✅ 给公司笔记本补 IPv6 出口的现实手段 |
| **公司 TCP 出站全自由** | `portquiz.net` 的 `443/8080/8443` 全 OPEN，且能连你腾讯云的 `22025` | ✅ **中继 / 直连方案的"通道"完全没问题** |
| 公司有 HIPS + EDR | 火绒 `HipsDaemon` / `HRWSCCtrl` **运行中** | ⚠️ 装内核驱动类方案有告警 / 被拦风险 |
| 家里上行 46 Mbps | Ookla 实测 | 画质天花板由它决定，与走哪条路无关 |

> **核心洞察（v5 更新）**：v4 时瓶颈是「**家里没有入口**」；现在家里**明明有一条干净的入口**（公网 IPv6，无 NAT、只需网关放行），瓶颈转移到了「**公司这侧够不着**」。
> 而"够不着"这件事 —— **一部手机就能补上**。

### 路径 A（**v5 主攻**）：手机热点补 IPv6 + 家里 IPv6 直连

**思路**：公司这条有线/WiFi 出口没有 IPv6，但公司笔记本还有一个网络接口从没用上 —— **WiFi 连自己的手机热点**。手机 5G 实测有 IPv6，热点下游设备通常也能分到 IPv6 前缀。

```
[家里主机] --公网 IPv6--> 中国电信 IPv6 骨干 <--IPv6-- [手机 5G] --热点--> [公司笔记本 · Moonlight]
                                  ▲
                       唯一门槛：天翼网关放行 IPv6 入站
```

- **优点**
  - **公司端零安装**：Moonlight 便携版即可 —— 不装驱动、不碰火绒、不要管理员
  - **画质上限最高**：家里 46 Mbps 上行全用得上 → **1080p120 满血**
  - **零月费**（只有流量开销），不依赖任何第三方服务、不需要备案域名、不受反作弊厂商策略影响
- **代价（必须提前认清）**
  - ⚠️ **流量**：1080p120 @ 20 Mbps ≈ **9 GB/小时**；打 3 小时 ≈ 27 GB。**建议单独办一张大流量副卡**
  - ⚠️ **延迟**：5G 空口 + 跨网（手机运营商 → 电信），预计 **40–70 ms**。LOL 可接受（普通玩家本身 30–50 ms），但吃不满 120fps 的体感优势
  - ⚠️ **稳定性**：5G 信号波动会直接反映到画面码率上
- **两个前置条件（必须先验证，步骤见第七章）**
  1. 手机热点**下游设备**能否拿到 IPv6 全局地址（部分手机/ROM 默认只共享 IPv4）
  2. 天翼网关是否**放行 IPv6 入站**（默认拦截，这是此前手机 4G 测试失败的最大嫌疑）

### 路径 A′（**已确认失败，但保留为长期最优解**）：申请公网 IPv4 + 端口转发

- 原为 v4 主攻路线，**用户打 10000 申请未成功** —— 运营商不给家宽公网 IPv4
- 若日后政策松动、或换运营商/换套餐，可立刻复活：拿到公网 IPv4 → 网关端口转发（Sunshine 的 `upnp = enabled` 已开，甚至不用登网关后台）
- **它是延迟最低、画质最好、对反作弊最友好的方案**，只是当前拿不到

### 路径 B（**可立即启用**）：腾讯云 frp 中继

- 公司端实测**能连 `193.112.118.168:22025`** → **中继通道完全可行**（frp 走任意端口都行）
- ⚠️ **5 Mbps 是硬伤**：只够 1080p60 @ 4~5 Mbps，画质明显缩水，达不到"画质好"
- 升级选项与代价：按带宽升级（如 20 Mbps）月费上升；**按流量计费更不可取** —— 1080p120 @ 20 Mbps ≈ **9 GB/小时**，长期串流成本无法承受
- 定位：**先跑起来、验证链路与手感**的过渡方案，同时等公网 IP

### 路径 C（**兜底**）：网易UU远程 / ToDesk（两端都已有痕迹）

- 10 分钟可用、**不受 CGNAT / 对称 NAT / 端口限制**（走厂商国内中转，且厂商带宽远大于自建中继）
- 网易UU远程是**专为游戏**设计的远控，比 ToDesk 更贴合"打游戏"场景
- 延迟约 30–60ms → 办公够用，**打大乱斗团战会有可感知的跟手差异**
- ⚠️ 反作弊风险最高档（见第五节）
- 定位：**A 未获批、B 画质不够时的现实选择**，或临时救急

### ❌ 已排除

| 方案 | 排除原因 |
|---|---|
| **Tailscale / ZeroTier 打洞** | ❌ **公司是对称 NAT + 多出口** → 打洞不可行（v3 曾列为次选，v4 判死）；退化走境外 DERP 中继延迟极差 |
| IPv6 直连（**公司有线/WiFi 这条出口**） | 企业网不发 IPv6 —— 🔄 v5 精确化：可用**手机热点**绕过，见路径 A |
| IPv4 端口转发（**当前状态**） | 家里是 CGNAT，且 **10000 申请公网 IPv4 被拒** → 当前不可用（保留为路径 A′） |
| **IPv6 隧道类**（HE 6in4 / Teredo / Cloudflare WARP） | 6in4 需放行 **IP 协议 41**（企业防火墙几乎不可能放）；Teredo / WARP 回程绕行，延迟 150 ms+ → 办公凑合、**打游戏不可用** |
| Windows 远程桌面（RDP） | 无 GPU 画面、刷新率锁 30、输入延迟高，不能打游戏 |
| TeamViewer / AnyDesk | 办公向设计，帧率与延迟都不达标 |
| 大带宽按流量中继 | 1080p120 约 9 GB/小时，流量成本不可持续 |

---

## 三、目标参数（**1080p120 定档**）

| 用途 | 分辨率 | 帧率 | 编码 | 码率 | 上行占用 |
|---|---|---|---|---|---|
| **首发默认** | 1920×1080 | **120** | **H.265** | **22 Mbps** | 47% |
| 优化后（首选） | 1920×1080 | 120 | **AV1** | 16–18 Mbps | 35–39% |
| 弱网兜底 | 1920×1080 | 60 | H.265 | 10 Mbps | 22% |
| 有余力再上 | 2560×1440 | 120 | AV1 | 30 Mbps | 65% |
| ❌ 不推荐 | 2560×1440 | 170 | AV1 | 45+ Mbps | ~100% |

**编码策略**：先用 **H.265** 跑通（兼容性最稳）→ 确认稳定后切 **AV1**（公司端 780M 支持 AV1 硬解，同画质可省约 20–30% 码率，画面更干净）。

---

## 四、延迟预算（目标 < 35ms）

| 环节 | 耗时 | 说明 |
|---|---|---|
| 家：采集 + NVENC 编码 | 5–10 ms | 1080p120 H.265/AV1 |
| 家：上行排队 | 1–3 ms | 码率留 50% 余量时 |
| 公网往返（家 ↔ 公司） | 8–25 ms | 同城 8–15ms，跨省 20–35ms |
| 公司：解码 + 渲染 | 3–6 ms | 780M 硬解 |
| 公司：显示器一帧 | **0–17 ms** | **60Hz 屏 = 16.7ms 硬成本**；144Hz 屏仅 ~7ms |
| **合计** | **20–45 ms** | 打大乱斗的临界体验线约在 40ms |

> 📌 **公司屏刷新率是硬成本**。若是 120/144Hz 屏，务必到「设置-系统-屏幕-高级显示」把刷新率手动调到最高。

---

## 五、反作弊风险（简版，细节你说稍后再展开）

**事实**：腾讯从未公布"用远控会封号"的条款，但社区有**大量十年封禁案例**，理由是"检测到第三方软件"，与远控软件在后台高度相关；**"远程操控着玩游戏"被反复指为最高风险场景**。

**本机现状不干净**：已存在 ToDesk / 网易UU远程 / MuMu 的虚拟显示驱动，而这些虚拟显示与虚拟输入设备正是 ACE/TP 反作弊的重点扫描特征。

**可用的降低手段**（无法归零）：
1. 优先用 **Sunshine**（用户态进程 + 系统 API 注入输入，不装虚拟显示器、不装内核驱动）
2. 公司端用 **Moonlight 便携版**（不写注册表、不留服务）
3. 游戏前停用国产远控服务与虚拟显示设备
4. 绝不用任何宏 / 连点 / 自动化映射
5. 一个天然优势：游戏看到的仍是**家里的 IP**，不会触发异地登录风控

---

## 六、实施计划（v3）

### Phase 0 · 前置验证（**基本完成**）
- [x] 家侧硬件与带宽实测（4070S / 7800X3D / 上行 46.36M / 丢包 0%）
- [x] 判定 IPv4 为 CGNAT
- [x] **家里 IPv4 NAT 类型复测 → 锥形（端点无关映射 / EIM），打洞可行** ✅（推翻 v2 的"对称 NAT"误判）
- [x] 确认家侧有公网 IPv6
- [x] 公司端自测结果回收：**纯 IPv4 网络、无 IPv6**；屏幕 2560×1600@**120Hz**；发现火绒 HIPS + EDR
- [x] Sunshine 已安装、服务运行、编码器三件套可用、凭据已建、双栈配置已生效
- [ ] **公司端跑 `net-test-v2.ps1`** ← 唯一还缺的技术验证（见第七节）
- [ ] **打 10000 号申请公网 IPv4** ← 与上一条并行；零成本，但可能一步解决问题

### Phase 1 · 家里端（**只剩电源设置没做**）

| 项 | 状态 |
|---|---|
| Sunshine v2026.906.222525 | ✅ `C:\Program Files\Sunshine\` |
| 服务 | ✅ `SunshineService` / LocalSystem / 开机自启 / Running |
| 编码器 | ✅ `h264_nvenc` / `hevc_nvenc` / **`av1_nvenc`**（含 10-bit） |
| 管理凭据 | ✅ `admin` / `Sunshine2026` |
| 双栈监听 | ✅ `address_family = both`，已验证 `[::]:47984 / 47989 / 47990 / 48010` |
| UPnP | ✅ `upnp = enabled`（**等路径 A 拿到公网 IP 后才有意义**） |
| 电源与显示器 | [ ] 关闭显示器 = 从不、睡眠 = 从不（否则采集黑屏）← **待你点** |

#### ✅ 曾经的阻塞项：Sunshine 默认只监听 IPv4 —— **已解决**

安装后实测（2026-09-10）：全部监听都是 `0.0.0.0:47984/47989/47990/48010`，IPv6 回环 `::1:47990` 直接被"积极拒绝"（根本没绑定）。

**你已在 Web UI 里改好了**，当前 `C:\Program Files\Sunshine\config\sunshine.conf` 内容为：

```ini
address_family = both
upnp = enabled
```

重启后日志确认两行配置都被正确解析（`config: 'address_family' = both` / `config: 'upnp' = enabled`），监听已变成双栈：

```
TCP [::]:47984    TCP [::]:47989    TCP [::]:47990    TCP [::]:48010
```

> 虽然公司没有 IPv6 让这条路暂时用不上，但**开着双栈没有副作用**，而且以后万一公司网络升级 IPv6，改都不用改。

#### Phase 1 已确认的环境事实

| 项 | 实测值 |
|---|---|
| 安装目录 | `C:\Program Files\Sunshine\` |
| 配置文件 | `config\sunshine.conf`（安装时为空，0 字节） |
| 凭据文件 | `config\sunshine_state.json`（创建凭据后生成） |
| 日志 | `config\sunshine.log`（**排查问题第一现场**） |
| 显示器 | 2560×1440 @ 170.002Hz，HDR 容器，HAGS 已启用 |
| Web UI | `https://localhost:47990`（自签名证书，浏览器需点"继续访问"） |
| Web UI API | **HTTP Basic 认证**（`WWW-Authenticate: Basic realm="Sunshine Gamestream Host"`），非 cookie 会话 |
| 首次设置 API | `POST /api/password`，JSON: `{newUsername, newPassword, confirmNewPassword}` |


### Phase 2 · 打通链路（按路径 A / B 二选一）

**路径 A —— 只适用"申请到公网 IPv4"的情况（公司端零安装，最优先）**
- [ ] 家里：确认网关端口转发生效，或让 Sunshine 的 UPnP 自动映射
- [ ] 手机 4G 直连验证：`http://公网IP:47990` 能打开 Web UI 即成功
- [ ] 公司：Moonlight 便携版 → 填 `公网IP:47989` 配对（一次性 PIN）

**路径 B —— Tailscale（不依赖电信）**
- [ ] 家里：装 Tailscale 并登录（需 UAC）
- [ ] 公司：装 Tailscale 并登录（需管理员；**留意火绒/EDR 弹窗**）
- [ ] 公司：Moonlight 便携版 → 填**家里的 Tailscale IP（100.x.x.x）**配对
- [ ] 首测参数 **1920×1080 @ 120 / H.265 / 22 Mbps**，开性能浮层看 encode / network / decode 分项

### Phase 3 · 调优
- [ ] Windows 鼠标加速关闭（"提高指针精确度"），缩放 100%
- [ ] 游戏内：**无边框窗口** + 分辨率与串流一致 + 刷新率"不封顶" + 关垂直同步
- [ ] Moonlight 关 V-Sync（换更低延迟）
- [ ] 跑顺后切 AV1，码率降到 16–18 Mbps
- [ ] 公司屏确认跑在 **120Hz**（实测已是 120Hz，串流时再核一次）
- [ ] 若走路径 A 且公网 IP 会变，配 DDNS

### Phase 4 · 兜底与卫生
- [ ] 保留 ToDesk（**当前已在用，已验证可用**）与网易UU远程作为应急通道
- [ ] 需要时在腾讯云部署 WireGuard / DERP 兜底（注意 5 Mbps 限制）
- [ ] **游戏前停用国产远控服务与虚拟显示设备**（ToDesk / GameViewer / MuMu 的 Virtual Display）

---

## 七、现在需要你做的事（v5）

### ⚠️ 前提：公网 IPv4 申请被拒 → 主攻方向改为「手机热点 + 家里 IPv6 直连」

| 路线 | v4 判决 | v5 修订 |
|---|---|---|
| IPv6 直连 | ❌ 死（公司无 IPv6） | 🔄 **复活** —— 家里侧条件已全部核实合格，公司侧可借**手机热点**补 IPv6 |
| P2P 打洞（Tailscale / ZeroTier） | ❌ 死 | ✅ 维持死判（公司对称 NAT + 多出口） |
| 申请公网 IPv4 | ✅ 主攻 | ❌ **申请被拒** → 降级为"长期最优解"（路径 A′） |
| 出站端口自由度 | ✅ 意外地好 | ✅ 维持（支撑路径 B 中继可行） |

**v5 路线表：**

| 优先 | 路线 | 公司端代价 | 能达到的画质 | 卡点 |
|---|---|---|---|---|
| **A** | **手机热点补 IPv6 + 家里 IPv6 直连** | **零安装**（只要 Moonlight 便携版） | ✅ **1080p120 满血** | ① 热点下游有无 IPv6 ② 家里网关是否放行入站 |
| B | 腾讯云 frp 中继（现在就能做） | 零安装 | ⚠️ 仅够 1080p60 | 服务器 5 Mbps |
| C | 网易UU远程 / ToDesk（兜底） | 零安装 | ⚠️ 延迟 + 反作弊风险 | 无 |

---

### ① ⭐ 当前最重要：验证 IPv6 路线能否成立（两步，约 10 分钟）

家里**已重新起好带日志的监听**（端口 38443，`:::38443 LISTENING` 已确认），下面两步直接决定走哪条路。

#### 步骤 1 —— 手机 5G 验证「家里 IPv6 入站是否放行」

用**手机（关 WiFi、走 4G/5G 流量）**扫下面这个二维码，或直接在系统浏览器里打开：

```
http://[240e:338:263:3600:29f1:e63f:d476:597e]:38443/
```

> 二维码文件：`ipv6-home-qrcode.png`（我已生成在项目目录，**用系统浏览器扫，别用微信扫一扫**——微信会拦非标端口的 http）

| 看到什么 | 含义 |
|---|---|
| 页面显示 `IPV6-INBOUND-OK` | ✅ **家里 IPv6 入站是通的** —— 好消息，路子活了 |
| 一直转圈 / 打不开 | ❌ 大概率是**天翼网关拦了 IPv6 入站** → 看下面 ② |

> 打不开也没关系：**家里服务端有访问日志**，我能判断请求到底有没有到达 —— 只要你告诉我"试过了"即可。

#### 步骤 2 —— 手机热点验证「公司笔记本能否拿到 IPv6」

这一步决定这条路的上限（能不能真的在公司上网）：

1. 手机**开热点**（进热点设置确认 **IPv6 / 流量共享** 是开的；部分国产 ROM 默认只共享 IPv4）
2. **公司笔记本连上这个热点**（先断开公司 WiFi 或让热点优先）
3. 跑我准备好的脚本 `hotspot-ipv6-test.ps1`（**已放在家里桌面** `C:\Users\xxl\Desktop\`，用 ToDesk 文件传输拉到公司电脑 —— 别复制粘贴文本）
4. 结果会自动写到公司电脑桌面 `hotspot-ipv6-result.txt`，发我

> 脚本是**纯 ASCII、无 BOM**，免疫复制粘贴损坏；它一次就把"有没有 IPv6 + 能不能连到家里"两件事都测了。

#### 两步的四种组合 → 直接决定走哪条路

| 步骤1（手机直连家里） | 步骤2（笔记本有 IPv6） | 结论与下一步 |
|---|---|---|
| ✅ | ✅ | 🎉 **全通** → 直接进 Phase 2 配对，**1080p120 满血**，成本只有流量 |
| ✅ | ❌ | 手机热点不给下游 IPv6 → 改用 **USB 共享 / 蓝牙共享**，或退路径 B 中继 |
| ❌ | ✅ | 家里网关拦入站 → 按 ② 放行网关 IPv6 防火墙 |
| ❌ | ❌ | 两条都堵 → 走路径 B（腾讯云中继）；或再争取公网 IPv4 / 换运营商 |

---

### ② 若卡在「家里网关拦 IPv6 入站」：三种放行办法

天翼网关**默认拦截 IPv6 入站**（IPv6 无 NAT，安全性全靠网关防火墙），这是此前手机测试失败的最大嫌疑。

| 办法 | 操作 | 可行性 |
|---|---|---|
| **1. 网关里关 IPv6 防火墙** | 登录 `192.168.1.1` → 安全 / 防火墙 → **IPv6 防火墙** → 关闭或调成"低" | 天翼网关多数型号有此开关；**需要后台密码**（找回阶梯见 §1.4） |
| **2. 光猫改桥接 + 自备路由器** | 让天翼网关只做光猫，用你自己的路由器 PPPoE 拨号 → 完全掌控 IPv6 防火墙与端口放行 | 最彻底，但**改错会全屋断网**，务必在家时操作 |
| **3. 退路径 B** | 不做入站放行，改用腾讯云中继 | 一定能通，但画质降到 1080p60 |

> ⚠️ **安全提醒**：IPv6 是"无 NAT 直通" —— 放行意味着那个地址**所有端口都对公网可见**。建议只放行串流必要端口（`47984-48010` / `47989` / `48010`），用完可关。别把 Windows 的 `445` / `3389` 之类暴露出去。

---

### ③ 提前准备：流量（步骤 2 通过的话）

- 1080p120 @ 20 Mbps ≈ **9 GB/小时**；打 3 小时 ≈ 27 GB
- **建议单独办一张大流量副卡**（或用现有套餐先试一晚测准真实消耗）
- 流量吃紧时的降档方案：1080p60 @ 8 Mbps ≈ 3.6 GB/小时（画质换成本）

---

### ④ 顺手把家里电源设置改掉（1 分钟）

`设置 → 系统 → 电源和电池 → 屏幕和睡眠`：**关闭屏幕 = 从不**、**睡眠 = 从不**。否则人不在家时显示器关闭会导致采集黑屏。

---

### ① ToDesk 连接方式 —— ✅ **已由 AI 从被控端反查完成，你不用再找状态栏**

你反馈"找不到状态栏"（新版 ToDesk 把 P2P / 中转标识收进了设备详情面板，确实不好找）。我改用更硬的办法：**直接在家里主机的进程层面抓 ToDesk 的实时连接**，结论见 §1.6。摘要：

| 抓到什么 | 说明 |
|---|---|
| 只与 ToDesk 自家服务器 (`219.151.138.225:443/8080`、`118.24.225.33:443`) 保持 TCP 长连接 | 走厂商侧 |
| 与公司出口 `117.188.24.89` **无任何 TCP 直连记录** | 至少 TCP 层没有直连 |
| 文件传输会话 `planb:1 ... p2p:0` | 该会话明确走**中转** |
| ✅ **但公司能出站到 8080 非标端口** | **重要利好**（说明不是 80/443 白名单） |

**这一项已完成，不用再花时间找界面标识。** 真正还缺的是 UDP 侧的硬数据 → 见 ②。

### ② 公司网络实测 —— ✅ **已完成**（`net-test-v2.ps1` 结果已回）

脚本跑通，原始结果见 `net-test-v2_20260910_163314.txt`。核心数据：

| 测试项 | 结果 | 判决 |
|---|---|---|
| IPv6 | `IPv6 local : NONE` | ❌ 纯 IPv4 |
| **TCP 出站** | `baidu:443` / `qq:443` / `aliyun:80` / `portquiz:443,8080,8443` **全 OPEN**；**你腾讯云的 `80/443/22025` 也全 OPEN** | ✅ **任意端口出站自由** |
| UDP 出站 | 多台 STUN 均收到回包（`stun.qq.com` 超时是它自身问题） | ✅ UDP 能出能回 |
| **NAT 类型** | 同一本地端口 `46001` 问不同 STUN → 映射端口 `16993 / 16994 / 17011 / 43681` **各不相同**；出口 IP 出现 `117.188.24.89` 与 `117.188.118.254` **两个** | ❌ **对称 NAT + 多出口 → 打洞不可行** |
| 管理员权限 | 当前会话非管理员，但账号 `ybtdevxxl` **在 Administrators 组内** | ⚠️ 可提权（点 UAC 即可） |
| 已装软件 | `Clash Verge` / `WireGuard` / `ToDesk` / 火绒 | 🎁 WireGuard 现成（但打洞已判死，用处有限） |
| 安全软件 | **火绒 `HipsDaemon` + `HRWSCCtrl` 运行中**；`aTrust` / `edr_monitor` / `savsvc` / Defender 全系 **Stopped** | ⚠️ 火绒会拦驱动；但**无强制 EDR 管控**（好消息） |

> 这轮也验证了 v2 脚本的价值：v1 报的"端口白名单"确是误判，v2 用真实靶子测出**出站完全自由** —— 这条结论直接支撑了路径 B（frp 中继）的可行性判断。

### ⑤（可选，长期）公网 IPv4 仍值得换个渠道再试一次

被拒不代表永久关闭。它是**延迟最低、画质最好、不依赖任何第三方**的方案，值得换个说法/渠道再争取：

| 渠道 | 话术 / 要点 |
|---|---|
| 再打 10000 | 换时段、换客服；说法改成："现在分到 `100.64` 开头的内网地址，**公司 VPN 连不回家里的 NAS**，需要公网 IP 才能访问" |
| 小翼管家 App | 部分地区有自助申请入口，比电话更快 |
| 线下营业厅 | 当面申请，权限通常比电话客服大 |
| 换运营商 / 换套餐 | 移动、联通在部分地区对公网 IP 更宽松；也可直接问"企业宽带"报价 |
| 工信部申诉 | **最后手段**（CGNAT 用户申请公网 IP 属合理诉求），耗时长，前三招先走完 |

> 一旦拿到公网 IPv4，**立刻切回路径 A′** —— 那才是这个方案的最优形态（零第三方、延迟最低、公司端零安装）。

### 附：原 v4 的申请话术（留档）

> "我家里需要在外网访问自己的监控和 NAS，现在分到的是 100.64 开头的内网地址，能不能帮我换成公网 IP？"

> 申请时**强调"不用开网站、不需要备案域名"，纯自用监控 / NAS**，通过率更高。

---

## 附 C：v2 阶段的 IPv6 入站验证过程（已完成，留存备查）

### ① 手机测 IPv6 入站（1 分钟，决定性）
家里当前**已开着临时监听**（端口 38443，**带访问日志版**）。请：

1. 手机关掉 WiFi，**用 4G/5G 流量**
2. 浏览器打开：
   ```
   http://[240e:338:263:3600:e591:cb62:3503:8a23]:38443/
   ```
3. 看到 `IPV6-INBOUND-OK` → ✅ **网关放行 IPv6 入站，走路径 1（最优）**
   打不开 / 超时 → 网关拦了入站，走路径 2（打洞），或登录网关放行

> 注意：**不要用 ping 判断**。Windows 默认拦掉 ICMPv6 入站，ping 不通不代表 IPv6 不可用，必须用这个 TCP 测试。

**日志验证法（本次新增，用于排除误判）**

监听会把每个到达的请求写入日志，因此判定不依赖手机浏览器是否正确渲染：

| 现象 | 日志 | 判定 |
|---|---|---|
| 手机看到 `IPV6-INBOUND-OK` | 有记录 | ✅ 入站通 |
| 手机页面打不开 | **有记录** | ✅ 入站通（只是浏览器/网速问题） |
| 手机页面打不开 | **无记录** | ❌ 入站被网关拦截 |

日志文件：`%TEMP%\wb_ipv6test\inbound.log`（形如 `[2026-09-10T07:42:50Z] REQ from=<手机地址> ...`）

> 监听进程随会话结束可能失效。**测试前若间隔较久，让 AI 重新起一次**（几十秒即可）。
> 另：之前那个残留在 38080 端口的旧监听本次已成功清理，端口已释放。

#### ⚠️ 日志法的一个重要局限（本次踩坑，2026-09-10 修正）

临时监听是用 `http.createServer` 实现的，**只在收到完整 HTTP 请求时才写日志**。
因此：**纯 TCP 探测（如 ping.pe 的端口检查）只做三次握手、不发 HTTP 请求，连接成功也不会留下日志。**

结论：**"ping.pe 显示 Connected" 与 "日志无记录" 可以同时成立，二者不矛盾**。
- 判断"TCP 层是否可达" → 看 ping.pe / itdog 等外部探测结果
- 判断"HTTP 层是否可达" → 看日志 + 手机浏览器实际渲染

#### 本次实测记录（2026-09-10）

| 时间 | 测试方式 | 结果 | 有效? |
|---|---|---|---|
| 15:42 | 本机 PowerShell 访问公网地址（内网回环） | HTTP 200，日志有记录 | 仅证明本机自通 |
| ~15:50 | 手机 **连 WiFi** 访问 | 打不开 | ❌ 无效（手机此时无 IPv6，且走回环易误判） |
| ~15:55 | 手机 **4G/5G** 访问 | 页面无响应、不报错；**日志无记录** | ✅ 有效，HTTP 层未到达 |
| ~16:00 | 手机扫码 **tcp6.ping.pe** 探测 | 用户反馈"通了" | ✅ TCP 层可达（待复核细节） |

**综合判定**：**外网 → 家里的 TCP 层大概率可达**（ping.pe 探测），
但手机浏览器的 HTTP 请求未到达 —— 二者差异可能来自手机侧（运营商 IPv6 路由 / 浏览器限制非标端口 http）。
**下一步用真实业务端口复核**：Sunshine 装好后，用 Moonlight 直接从公司连，成不成是最终标准。
（Sunshine 用 47989/47984/48010 等端口，与 38443 不同，网关若做端口白名单需另放行。）

### ② 把自测脚本带到公司电脑跑一遍（**旧版，已跑完，已被 `net-test-v2.ps1` 取代**）
文件：`公司电脑网络自测.ps1`（同目录）

```
先在开始菜单打开 Windows PowerShell，然后：
powershell -ExecutionPolicy Bypass -File "公司电脑网络自测.ps1"
```

它会输出一台设备「能不能支撑远程串流」的完整画像，重点看三行：
- `IPv6 出网 : ...` → 决定能否走 IPv6 直连
- `STUN ... -> 通` 与 `NAT 判断 : ...` → 决定打洞可行性
- `家里 IPv6:38443 -> ...` → 若这行是"通"，说明**从公司到家里已经打通了**

---

## 附 A：端口与命令

```powershell
# Sunshine 需要的入站规则（安装时一般会自动创建，失败时手动补）
New-NetFirewallRule -DisplayName "Sunshine TCP" -Direction Inbound -Protocol TCP -LocalPort 47984,47989,47990,48010 -Action Allow
New-NetFirewallRule -DisplayName "Sunshine UDP" -Direction Inbound -Protocol UDP -LocalPort 47998-48000,48002 -Action Allow

# Moonlight 命令行示例（1080p120 / 22Mbps）
moonlight stream <家里IPv6> "Desktop" -1080 -120fps -bitrate 22000

# Moonlight 快捷键
# Ctrl+Alt+Shift+S  性能浮层    Ctrl+Alt+Shift+Z  切换鼠标捕获      Ctrl+Alt+Shift+Q  退出串流
```

**已知坑**
- 显示器进入睡眠 → Sunshine 抓不到画面、串流黑屏，务必关闭显示器休眠
- 多显示器时需指定 `output_name`，指错会串到错误屏幕或全黑
- 独占全屏可能因分辨率切换导致采集中断 → 统一用"无边框窗口"
- 若走端口转发（本方案用不到），务必改非默认端口 + Sunshine Web UI 用强密码

## 附 B：工程备注（本机探测踩过的坑）

- 本机 PowerShell 工具的 stdout 会被吞掉 → 需要把结果 `Out-File` 落盘再用 Read 读
- PowerShell 里 `[byte] -shl 8` 会溢出归零，字节拼 16 位整数必须先 `[int]` 转换
- 用 `Get-Content -Raw` + `Out-File` 加 BOM 会把 UTF-8 中文按 GBK 解码后重写而**永久损坏文件**；加 BOM 应使用字节级操作 `WriteAllBytes` 前置 `EF BB BF`
- 本机 PATH 被裁剪，脚本里调用 `ping` / `netsh` 会找不到 → 用 `$env:SystemRoot\System32\` 绝对路径
- 一批防火墙入站规则指向的 node.exe 路径已不存在（失效规则），`C:\Users\xxl\AppData\Roaming\nvm\v23.0.0\node.exe` 才有有效的 Public 档全端口放行规则
- **"从外部验证 IPv6 入站"没有可用的自动化手段**（2026-09-10 实测全部失败），必须用真实外部设备（手机 4G）验证：
  - `check-host.net` API：`check-tcp` 对 IPv6 一律返回 `{"error":"invalid_url"}`（带/不带方括号、带 http:// 前缀都试过）
  - `ping.pe` / `tcp6.ping.pe`：接受 IPv6 目标，但结果是 **JS 异步渲染**，静态抓取只能拿到 `Connecting to ...` 与 `Snapshot readiness: waiting_for_results`
  - 公共 CORS 代理（codetabs / allorigins / corsproxy / thingproxy / Jina Reader）：要么 522、要么需要 API key、要么直接被 GFW 拦截
  - `hackertarget.com/nmap`：已改为需要 API key
- 因此本项目采用**「手机 TCP 测试 + 服务端访问日志」双证据**方式判定入站可达性

### ⚠️ 附 B 补充（v3，2026-09-10）：两个"看起来专业、其实是错的"测试陷阱

这两条是本项目**已经踩过并已修正**的坑，以后再写网络探测脚本必须避开：

**陷阱 1：NAT 类型判定 —— 每个 STUN 换一个新 socket**
- ❌ 错误做法：`for each stun: 新建 socket → sendto → 看映射端口`。因为**本地端口每次都变了**，运营商/网关必然分配不同的公网映射端口 —— 这是任何 NAT 类型都会出现的结果，**不能推出"对称 NAT"**
- ✅ 正确做法：**同一个 socket（同一个本地端口）连续问多个 STUN 服务器**，比较映射端口是否一致：
  - 一致 → 端点无关映射（Cone / EIM）→ 打洞可行
  - 不一致 → 对称 NAT → 打洞难
- 本项目实测（正确方法）：本地 55001 → 恒为 `1.204.100.17:3051`；55002 → 恒为 `:3063` → **结论是锥形 NAT，v2 的"对称 NAT"是误判**

**陷阱 2：判断"端口白名单"时用了根本没在监听的靶子**
- ❌ 错误做法：连 `114.114.114.114:8080` 失败 → 就断定"公司封了非标端口"。实际上**那个 DNS 服务器压根没开 8080**，失败是必然的，跟防火墙无关。同理 `github.com:443` 在国内常被 DNS 污染/阻断，也**不能**作为"443 被封"的证据
- ✅ 正确做法：用**确定在监听该端口**的靶子，且最好有"全端口监听"型服务：
  - `www.baidu.com:443`、`www.qq.com:443`（国内基线，验证 443 是否真的可用）
  - `portquiz.net`（**监听所有 TCP 端口**，在它上面测 8080/8443 才有意义）
  - 自有服务器 `193.112.118.168:80/443`（nginx 确实在监听）
- 判别逻辑：`REFUSED`（立即拒绝）= **路径是通的**，只是对端没开这个端口；`TIMEOUT`（一直等）= **真的被拦或丢包**

**陷阱 3（方法论）：日志监听只能证明 HTTP 层，不能否定 TCP 层**
- `http.createServer` 只在收到完整 HTTP 请求时写日志。纯 TCP 端口探测（三次握手即断）**成功也不会留痕**
- 所以"探测显示 Connected"与"日志空白"可以同时为真，**不可据此判定入站被拦**