xpcool/workbuddy.xpcool.com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0f94521086
workbuddy.xpcool.com/远程游戏串流方案_家到公司.md

48 KiB
Raw Blame History

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

目标：在公司电脑上远程控制家里主机，能正常游玩《英雄联盟》快节奏娱乐模式（海克斯大乱斗类，团战密集、吃操作延迟）。 版本：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
出口 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 · 前置验证（基本完成）

  • 家侧硬件与带宽实测（4070S / 7800X3D / 上行 46.36M / 丢包 0%）
  • 判定 IPv4 为 CGNAT
  • 家里 IPv4 NAT 类型复测 → 锥形（端点无关映射 / EIM），打洞可行 ✅（推翻 v2 的"对称 NAT"误判）
  • 确认家侧有公网 IPv6
  • 公司端自测结果回收：纯 IPv4 网络、无 IPv6；屏幕 2560×1600@120Hz；发现火绒 HIPS + EDR
  • 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 内容为：

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：端口与命令

# 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"与"日志空白"可以同时为真，不可据此判定入站被拦