26 KiB
26 KiB
2026-09-10 工作日志
家庭主机远程串流方案设计(公司电脑 → 家里主机)
类型:REQ(方案设计,待确认后实施)
触发需求
在公司电脑远程控制家里这台主机,要求速度快、画质好,能打《英雄联盟》快节奏娱乐模式(海克斯大乱斗类)。
本次实测底账(家里主机 = 本开发机)
- GPU:NVIDIA RTX 4070 SUPER(驱动 32.0.15.9186),支持 NVENC H.264/H.265/AV1 硬编;另有 7800X3D 核显 AMD Radeon Graphics
- CPU/内存:Ryzen 7 7800X3D(8C/16T) / 31.2 GB
- 系统:Windows 11 专业版 build 26200
- 显示器:AOC 2560×1440 @ 170Hz
- 网络:Realtek 2.5GbE,链路 1Gbps,内网 IP
192.168.1.30,网关192.168.1.1(HTTP 200 可登录) - 宽带(Ookla CLI,电信上海节点 id 3633):下行 943.82 Mbps / 上行 46.36 Mbps / 空闲延迟 33.91ms / 丢包 0.0%
- 出口 IP:
1.204.100.17(中国电信广东,与历史记录的 1.204.105.116 同段,动态)
关键发现
- 上行 46M 是整个方案的唯一硬瓶颈,可支撑 2K 90–120fps @ 30Mbps 或 1080p 120–144fps @ 20–25Mbps;不足以支撑 2K 170Hz 满刷。
- 本机已存在远控残留驱动:
Todesk Virtual Display Adapter、GameViewer Virtual Display Adapter(网易UU远程组件)、MuMu Virtual Display Adapter。这些虚拟显示/虚拟输入驱动是腾讯 ACE/TP 反作弊重点扫描特征。 - Moonlight 官方提供 Windows Portable 便携版(官方原话:for work/public PCs without the ability to install new programs)→ 完美解决公司电脑无管理员权限问题。
- 反作弊风险是真实存在的:社区有大量因远控软件在后台被判定"第三方软件"而十年封禁的案例,"远程操控着玩游戏"是最高风险场景。已写入方案第五节并给出降低措施。
产出
- 方案文档:
E:\Project\workbuddy.xpcool.com\远程游戏串流方案_家到公司.md(v1 草案,待确认) - 结论:主方案 = Sunshine(家)+ Moonlight 便携版(公司)+ 公网 UDP 直连;网易UU远程作为应急通道;Windows RDP / TeamViewer 明确不适用;硬件 KVM 延迟不达标。
待用户确认(阻塞下一步)
- 路由器 WAN 口 IP 是否等于
1.204.100.17(判断有无公网 IPv4,决定走端口转发还是组网) - 公司电脑:能否装软件 / 显卡型号 / 屏幕分辨率与刷新率
- 公司网络是否限制 UDP、是否有代理或行为审计
- 是否接受反作弊风险(若账号价值高,建议只作办公/挂机通道)
顺手记录
- PowerShell 工具在本机不回显 stdout(exit code 正常但无输出),需
Out-File落盘后用 Read 读取;Bash 内调用powershell.exe被安全策略拒绝。 - Cloudflare 测速端点在本地几乎不可用(上传 121KB/s、下载 0),国内测速改用 Ookla 官方 CLI(
install.speedtest.net可直连下载)。
追加:Phase 0 前置验证执行结果(同日 14:40–14:55)
三个决定性发现
- 家里 IPv4 是运营商级 NAT(CGNAT):
tracert第 2 跳 =100.64.0.1(RFC 6598 运营商专用段)→ v1 的"公网 IPv4 + 端口转发"方案彻底作废。 - 家里有公网 IPv6:
240e:338:263:3600::/64(RA 下发,电信)。可用地址240e:338:263:3600:e591:cb62:3503:8a23(Preferred)。→ IPv6 直连成为首选路径(IPv6 无 NAT,只需网关防火墙放行入站)。 - IPv4 侧为对称 NAT:STUN 实测映射端口每次不同(1986 / 1990)→ IPv4 打洞成功率低,但 IPv6 侧打洞前景好。
其他确认
- 网关 = 中国电信智能网关(天翼网关),LuCI 界面
/cgi-bin/luci,MAC88-C7-8F-A6-BC-43;密码找回阶梯已写入方案文档(贴纸 useradmin → telecomadmin/nE7jA%5m→ 小翼管家 App → 10000 号 → 恢复出厂;且方案本身不依赖路由器后台)。 - 本机 Windows 防火墙:Domain=开 / Private=关 / Public=开,以太网被判定为 Public;当前会话不是管理员,后续装 Sunshine 需用户点 UAC。
- 本机装有 Clash Verge(系统代理 127.0.0.1:7897 开关=0)与火绒(HipsDaemon/HRWSCCtrl)。
- 公司电脑(用户截图):Ryzen 7 7840H + Radeon 780M(RDNA3,VCN 4.0,支持 AV1 硬解)/ 32GB / 954GB,可安装软件。
- 画质定档 1080p120(H.265 22Mbps 起步 → 稳定后切 AV1 16–18Mbps)。
交付物
- 方案文档升级至 v2:
远程游戏串流方案_家到公司.md(架构重构为 IPv6 直连优先) - 新增
公司电脑网络自测.ps1(UTF-8 with BOM,已在临时目录实跑验证通过):检测设备/显示、IPv6 出网、代理与审计软件、TCP 端口自由度、UDP 出网 + STUN NAT 类型、到家里的链路。
待用户执行(阻塞下一步)
- 手机 4G/5G 打开
http://[240e:338:263:3600:e591:cb62:3503:8a23]:38443/看是否返回IPV6-INBOUND-OK(家里临时监听已起,端口 38443) - 公司电脑跑一次
公司电脑网络自测.ps1
本次踩坑(已沉淀到 MEMORY.md)
- PowerShell 工具 stdout 被吞、
[byte] -shl溢出归零、Get-Content -Raw+Out-File加 BOM 导致 UTF-8 中文被按 GBK 重写而永久损坏、PATH 被裁剪导致 ping/netsh 找不到、后台监听进程杀不掉、防火墙规则指向已失效的 node 路径。
追加:临时监听重启 + 引入「日志验证法」(同日 15:41–15:50)
类型:CHG
做了什么
- 清理旧监听:上次会话留下的两个后台监听(38443 / 38080)本次全部
Stop-Process成功,端口已释放(上次杀不掉的 38080 残留也清掉了)。 - 重起带访问日志的监听(端口 38443):新版
server.js把每个到达请求(来源 IPv6、UA、时间)追加写入%TEMP%\wb_ipv6test\inbound.log,本地自测已命中日志。 - 本机 IPv6 地址复查:
240e:338:263:3600:e591:cb62:3503:8a23仍为 Preferred(未变);另有...:29f1:e63f:d476:597e也是 Preferred。 - 防火墙规则复核:
C:\Users\xxl\AppData\Roaming\nvm\v23.0.0\node.exe有 Public 档 TCP+UDP、任意端口 的入站放行规则(因此该 node 起监听不会被本机防火墙吞掉,测试结果有效)。
关键结论:「从外部自动验证 IPv6 入站」没有可用手段
逐一实测失败:
| 手段 | 结果 |
|---|---|
check-host.net API(check-tcp) |
对 IPv6 一律 {"error":"invalid_url"}(方括号/无方括号/http:// 前缀均试过) |
ping.pe / tcp6.ping.pe |
接受 IPv6 目标,但结果为 JS 异步渲染,静态抓取只有 Connecting to ... + waiting_for_results |
| 公共 CORS 代理 codetabs | 522 |
| allorigins | Network connection lost(不足以作为证据) |
| corsproxy.io | 需 API key |
| thingproxy / Jina Reader | 空响应(被拦) |
| hackertarget nmap API | 已需 API key |
→ 定案:采用「手机 4G TCP 测试 + 服务端访问日志」双证据判定,即使手机页面渲染异常,只要日志有 REQ from= 记录即可确证入站通。
交付物更新
远程游戏串流方案_家到公司.md:第七节补充「日志验证法」判定表与日志路径;附 B 补充上述"外部探测不可用"的完整踩坑清单。%TEMP%\wb_ipv6test\server.js重写为带日志版本(并新增ext_probe.py,check-host.net 探测脚本,结论:该服务不支持 IPv6)。
追加:脚本跨设备损坏诊断 + 纯 ASCII 版交付(同日 15:47–15:55)
类型:FIX
现象
用户把脚本弄到公司电脑(E:\xxcool\project\workbuddy.xpcool.com\网络自测.ps1)执行后报错:
意外的标记"InterNetworkV6"—— 文件里AddressFamily]::InterNetworkV6丢了一个::IPv6 鍑虹綉 ... 涓嶹€?—— 中文乱码(UTF-8 字节被按 GBK 解码的典型样子)
诊断
- 本机
公司电脑网络自测.ps1第 35 行是正确的(带::),文件 BOM 完好(ef bb bf) - → 根因是走了"文本复制粘贴"而不是"传文件",粘贴链路丢了 BOM 与个别字符
- 乱码呈
鍑虹綉形态 = 字节仍是 UTF-8,只是缺 BOM → 加 BOM 即可救(非双重编码,可逆)
处置
- 新增纯 ASCII 版脚本
net-test.ps1(输出全英文、文件内无非 ASCII 字符)→ 免疫一切编码问题;已在本机实跑通过,自检行输出Script encoding : no BOM (file is pure ASCII - harmless) - 给了用户「一键修复已损坏文件」的命令(显式按 UTF-8 读 → 补
::→ 以带 BOM 的 UTF-8 写回) - 修复经验沉淀进 skill
windows-host-probe(新增"跨设备交付会静默损坏文件"一节)
手机 IPv6 入站测试结果(用户 15:47 执行)
- 用户手机访问
http://[240e:338:263:3600:e591:cb62:3503:8a23]:38443/→ 打不开 - 服务端日志无任何来自手机的记录(只有本机自测那条)→ 请求未到达家里主机
- ⚠️ 但此结论有前置条件未排除:用户手机可能本身没有 IPv6(4G/5G 未开 IPv6、或未关 WiFi),需先做对照测试(手机访问
ipv6.icanhazip.com/tcp6.ping.pe)才能定论是"网关拦入站"
其他
- 想借本机 Clash Verge 代理(127.0.0.1:7897)从境外节点验证入站 → Clash 未运行(7897 未监听),此路不通
- ⚠️ 腾讯云服务器 SSH 公钥认证被拒:
ssh -i CentOS.pem -p 22025 xxcool@193.112.118.168报Permission denied (publickey)(网络可达、走到认证阶段)。后续所有服务器部署动作会受阻,需与用户确认密钥/密码。
Phase 1 启动:Sunshine 已安装(16:04–16:12)
类型:CHG
完成项
- 下载 Sunshine v2026.906.222525 MSI(33,595,392 B,与官方发布字节数完全一致)+ Moonlight Portable x64 6.1.0(29,502,440 B)
→ 存于
C:\Users\xxl\Downloads\wb-stream\→ GitHub CDN 直连被打断(exit 56),改用镜像https://ghfast.top/成功,约 700KB/s(ghproxy.net、gh-proxy.com也返回 206 可用) - 提权安装成功(
Start-Process msiexec -Verb RunAs+ 用户点 UAC),退出码 0 - 服务
SunshineService(sunshinesvc.exe/ LocalSystem / Auto / Running) - 编码器探测:h264_nvenc、hevc_nvenc、av1_nvenc 全部可用(含 10-bit;AV1 的 YUV444 不支持属正常)
- 显示器识别:2560×1440 @ 170.002Hz,HAGS 已启用
- Web UI 凭据已创建:admin / Sunshine2026(
POST /api/password,字段newUsername/newPassword/confirmNewPassword)
⚠️ 关键阻塞:Sunshine 默认只监听 IPv4
- 实测
TCP 0.0.0.0:47984/47989/47990/48010;::1:47990连接被积极拒绝 → 完全无 IPv6 绑定 - 官方文档(docs.lizardbyte.dev v0.23.1 advanced_usage)确认配置项:
address_family = both(默认ipv4)→ 双栈upnp = on→ Sunshine 的 UPnP 实现含 IPv6 防火墙控制,可能自动放行网关入站
- 改法:编辑
C:\Program Files\Sunshine\config\sunshine.conf后重启服务(需管理员); 或走 Web UI(Configuration → Advanced → Address Family),Web UI 以服务权限运行,免管理员
工具与安全边界踩坑(重要)
Start-Process powershell.exe -Verb RunAs被安全策略拦截("spawns a child process that bypasses PowerShell command validation") → 无法用提权 shell 跑脚本;提权启动非 shell 的 exe(如 msiexec)可行curl -u user:pass(HTTP Basic 凭据)触发敏感内容审批并超时;按规则不重试、不绕过 → 该步交用户手动操作- PowerShell 工具默认是非管理员上下文:写
C:\Program Files\被拒("访问被拒绝")、Restart-Service报"无法打开服务"
入站判定方法论修正
- 临时监听用
http.createServer,只在收到完整 HTTP 请求时写日志;ping.pe 的纯 TCP 探测成功不会留日志 - → "ping.pe 显示 Connected" 与 "日志无记录" 可并存、不矛盾(TCP 层 vs HTTP 层)
- 用户 16:00 反馈"通了"按 TCP 层可达理解
用户手机 IPv6 前置条件已排除
- 手机(关 WiFi / 4G-5G)可访问
https://ipv6.icanhazip.com/→ 手机确有 IPv6,此前"打不开"的测试有效 - 但 HTTP 请求仍未到达家里 → 差异可能来自手机侧(运营商 IPv6 路由 / 浏览器拦非标端口 http)
下一步
- 用户在 Web UI 改
address_family(+ UPnP),重启服务 - 验证出现
TCP [::]:47989等 IPv6 监听 - 手机 Moonlight(局域网)先跑通配对,再走外网
16:10–16:30 公司端自测结果回收 → 路线二次重构(v3)
✅ 用户已完成 Sunshine 配置(已验证生效)
C:\Program Files\Sunshine\config\sunshine.conf=address_family = both+upnp = enabled- 日志确认解析成功:
config: 'address_family' = both/config: 'upnp' = enabled - 监听已变双栈:
TCP [::]:47984 / 47989 / 47990 / 48010(v2 的"IPv6 阻塞项"彻底解决) sunshine_state.json已存在(凭据已建)- 无害报错:
NvEnc: gpu doesn't support YUV444 encode(日志自称可忽略) - ⚠️ 虚拟手柄不可用:
gamepads.virtualhid-not-available(需 ViGEmBus 内核驱动,建议不装,抬高反作弊风险)
🔴 公司端实测(网络自测结果_20260910_160152.txt)→ IPv6 路线作废
- 公司 CPU:Ryzen 7 7840H + Radeon 780M;屏幕 2560×1600@120Hz(比假设的 60Hz 好一档)
- IPv6:本机无 v6 地址,v6 出网两条 DNS 全不通 → 公司是纯 IPv4 网络 ⇒ IPv6 直连彻底作废
- 高位 UDP 可出网:STUN(miwifi / hitv)均有回包,出口
117.188.24.89 - 系统代理开关=0 但服务器填了
127.0.0.1:7892(疑似装过 Clash 类客户端,待查) - 安全软件:
HipsDaemon(火绒 HIPS) +HRWSCCtrl(火绒安全中心) +edr_monitor+savsvc
🎯 重大纠正:家里 IPv4 是「锥形 NAT」,不是对称 NAT
- v2 测试方法错误:每个 STUN 用新 socket(本地端口变了)→ 映射端口必然不同 → 误得"对称 NAT"
- 正确方法(同一 socket 连问多个 STUN):本地 55001 → 恒
1.204.100.17:3051;55002 → 恒:3063 - ⇒ 端点无关映射(Cone/EIM),打洞可行 —— 这是本次最有价值的修正
- 已写
%TEMP%\wb_nat\nat_test.py作为可复用工具
🎯 第二个纠正:v1 脚本的"端口白名单"结论也是误判
- 靶子无效:
114.114.114.114:8080(该主机根本没开 8080)、github.com:443(国内 DNS 污染) - 已重写
net-test-v2.ps1(纯 ASCII、无 BOM、免疫复制粘贴),靶子换成真在监听的:www.baidu.com:443、www.qq.com:443、www.aliyun.com:80、193.112.118.168:80/443/22025、portquiz.net:443/8080/8443 - 本地实跑验证通过(家里侧:全部 OPEN,portquiz 全端口可达)
- 新增检查项:管理员权限自检 / 火绒·EDR 清单 / 本地代理端口监听 / 已装 VPN·远控软件
ToDesk 现成可用(重要旁证)
- 用户此刻正在公司用 ToDesk 控家里(说明公司↔家里的中转链路已验证可用)
- 家里这侧日志分析:ToDesk 文件传输会话为
planb:1 ... p2p:0(走中转,非 P2P) - 控制会话链路类型需看用户侧界面(
.xlog是压缩格式,挖不出)→ 已请用户查看界面显示"P2P直连"还是"中转" - ToDesk 的 RTC/QUIC 配置:
default_hard_codec: h265,br_limit 50000/100000
技术方案已重排(详见方案文档 v3)
- 路径 A(首选):申请公网 IPv4 + 端口转发/UPnP → 公司端零安装
- 路径 B(次选):Tailscale 打洞(家里锥形 NAT 是好基础)→ 公司端需管理员+TUN 驱动,可能触发火绒/EDR
- 路径 C(兜底):ToDesk / UU远程(已验证可连通,但延迟与反作弊风险)
- 路径 D(保底):腾讯云中继(仅 5 Mbps)
下一步(已交用户)
- 看 ToDesk 界面显示 P2P直连 还是 中转(5 秒,信息量最大)
- 公司电脑跑
net-test-v2.ps1,回传net-test-v2_*.txt - 打 10000 申请公网 IPv4
- 家里改电源设置(关屏=从不、睡眠=从不)
交付物
net-test-v2.ps1(新增,纯 ASCII)远程游戏串流方案_家到公司.md升级到 v3(路线重构 + 三处测试陷阱记录)
16:30 更新 · 公司端网络身份确认 + ToDesk 反查(本轮)
用户提供(ipconfig)
- 公司笔记本走 WiFi 接入企业网,网段
192.168.250.0/24,网关192.168.250.1 - IPv6 只有
fe80::链路本地地址 → 无 RA 全局地址,纯 IPv4 网络(硬结论,IPv6 路线彻底作废) - 出口 IP
117.188.24.89,全公司共享同一出口
AI 从被控端反查 ToDesk(用户无需操作,用户反馈"找不到状态栏")
- ToDesk 只与自家服务器保持 TCP 长连接:
219.151.138.225:8080、219.151.138.225:443、118.24.225.33:443 - 与公司出口
117.188.24.89无任何 TCP 直连记录;文件传输会话为planb:1 ... p2p:0(中转) - ⭐ 关键利好:公司允许出站到 8080 非标端口 → 公司不是"只放行 80/443"的白名单防火墙;若将来有公网 IPv4,Sunshine 的 47989/47990/48010 大概率可直连,腾讯云 frp 中继(任意端口)也具备可行性
- 家里 ToDesk 在多个 IPv6 UDP 端点监听(57062–57068,对应 3 个轮换的隐私扩展地址)+ IPv4
192.168.1.30:57065/57069;UDP 无连接、端点列表看不到对端,不能据此断定打洞失败,但打洞信心已下调 - 附带结论:家里 IPv6 有多个轮换隐私地址 → IPv6 直连必须配 DDNS(该路线已作废,仅留档)
交付 / 变更
net-test-v2.ps1已复制到家里主机桌面C:\Users\xxl\Desktop\net-test-v2.ps1(13,690 B),便于用户用 ToDesk 文件传输拉到公司电脑,避免复制粘贴损坏- 方案文档 §1.6 已补入公司接入方式与 ToDesk 反查结论;第七节 ① 改为"已完成,无需再找状态栏",② 增加 ToDesk 文件传输操作步骤
- 确认 v2 脚本已内置
193.112.118.168:80/443/22025的 TCP 连通性测试(可验证公司能否访问腾讯云,为 frp 中继铺路)
下一步(用户侧)
- 用 ToDesk 文件传输把桌面
net-test-v2.ps1拉到公司电脑并运行 → 回传net-test-v2_*.txt - 若 UDP 打洞数据不乐观 → 优先打 10000 申请公网 IPv4(路径 A,公司端零安装)
- 家里改电源设置(关屏=从不、睡眠=从不)
16:35 更新 · 公司端 v2 实测结果回执(路线定案)
来源:net-test-v2_20260910_163314.txt(公司电脑运行 v2 脚本,用户经 ToDesk 文件传输送达)
三条硬结论
- ❌ 公司是对称 NAT:同一本地 UDP 端口
46001问多个 STUN → 映射端口16993/16994/17011/43681各不相同;且公网出口有多个(117.188.24.89与117.188.118.254按目的地分流)→ P2P 打洞不可行(v3 曾把 Tailscale 打洞列为次选,本轮判死) - ❌ 公司无 IPv6(复核
IPv6 local : NONE)→ IPv6 直连彻底作废 - ✅ 公司 TCP 出站完全自由:
portquiz.net的443/8080/8443全 OPEN,连腾讯云193.112.118.168:22025也 OPEN → 任意端口的直连/中继"通道"毫无障碍
其他实测事实
- 管理员:当前会话非管理员,但账号
ybtdevxxl在 Administrators 组内 → 可提权 - 已装软件:
Clash Verge、WireGuard、ToDesk、火绒安全软件 - 安全软件:火绒
HipsDaemon/HRWSCCtrl运行中;aTrust/edr_monitor/savsvc/ Defender 全系 Stopped → 无强制 EDR 管控 - 屏幕:主屏 2560×1600@120(脚本报
1707×1067= 150% 缩放后的逻辑值),副屏 1920×1080 - UDP 出网可用,但
stun.qq.com:3478超时(该服务器自身问题,非本地限制)
路线定案(v4)
| 优先 | 路线 | 画质上限 | 公司端代价 |
|---|---|---|---|
| A(主攻) | 申请公网 IPv4 + 端口转发 / UPnP | 1080p120 满血 | 零安装 |
| B | 腾讯云 frp 中继(通道已验证可行,卡在 5 Mbps) | 1080p60 | 零安装 |
| C | 网易UU远程 / ToDesk(兜底) | 延迟 + 反作弊风险 | 零安装 |
核心洞察:唯一瓶颈是"家里没有公网入口";公司侧出站通道意外宽松。
交付
- 方案文档升级到 v4:新增
v3 → v4修订摘要、第二章「方案选型(v4 定案)」重排(Tailscale 打洞移入已排除)、第七节改为"主攻公网 IP"并附话术与三种客服应对 - 待用户执行:打 10000 申请公网 IPv4
16:41 用户提问 · 申请到的会是动态公网 IPv4 吗?
类型:REQ(咨询,未实施)
答复要点(已交付用户)
- 必然是动态的:家宽走 DHCP 动态分配,运营商不会给家宽静态 IP(静态属企业专线产品,需签约加钱)。10000 能做的只是把会话地址从 CGNAT 池(100.64.x.x)换到真公网池,本质仍是动态。
- 动态不影响方案:电信动态 IP 只要光猫不断线就长期不变(本机出口
1.204.100.17与历史1.204.105.116同属 1.204 段);再用xpcool.com子域做 DDNS(DNSPod API + 定时上报脚本,约 5 分钟粒度),Moonlight 端只填域名 → 图示"家里 WAN → DNSPod → 公司 Moonlight"链路。 - 比"动态"更该防的三个坑:
- 拿到的仍是
100.64.x.x/ 私网段 → 挂电话前必须确认"能否被外网直接访问" - 光猫路由模式造成双层 NAT → 需光猫改桥接,或光猫内给路由器 WAN 做 DMZ
- 家宽普遍封 80/443 → Sunshine 用 47989/47984-48010,不受影响
- 拿到的仍是
- 唯一可靠的验证法:手机流量查出口 IP,必须完全等于路由器 WAN 口 IP(且 WAN IP 非私网段)。
- 时机建议:10000 是 7×24,上班摸鱼时即可打电话登记;但改光猫/重启必须等回家做 —— 当前唯一远程通道是 ToDesk,一旦改崩断网就连带失去操作通道。
18:56–19:05 · 公网 IPv4 被拒 → IPv6 路线重启评估(v5)
类型:CHG
用户输入
"公网 ipv4 申请不到,ipv6 可以吗" —— 10000 申请公网 IPv4 被拒。
本轮实测(家里侧,19:00 复查)
- IPv6 出网全通:
ipv6.icanhazip.com/www.taobao.com/www.qq.com的 TCP 443 全部 OK - IPv6 地址三枚:
| 地址 | 后缀类型 | 状态 | 用途 |
|---|---|---|---|
240e:338:263:3600:29f1:e63f:d476:597e |
Suffix=Link | Preferred | ✅ 首选服务地址 —— 后缀永不轮换 |
240e:338:263:3600:e591:cb62:3503:8a23 |
Suffix=Random | Preferred | ⚠️ 隐私扩展,会轮换 |
240e:338:263:3600:51f3:a026:4256:a337 |
Suffix=Random | Deprecated | ❌ 废弃 |
- 默认路由 →
fe80::1;Public 档防火墙开启,node.exe有 Public/Private 入站 Allow 规则 → 本机侧不拦 - 监听已重起:
:::38443 LISTENING(PID 27508),日志%TEMP%\wb_ipv6test\inbound.log正常写入
关键论证(本轮最重要的一条推理)
v4 说"IPv6 判死",精确说法应是"公司那条有线/WiFi 出口没有 IPv6",而非"公司场景不可用"。 → 公司笔记本还有第二条出口从未被用上:手机 5G 热点(用户手机实测有 IPv6)。 → v5 主攻 = 手机热点补 IPv6 + 家里 IPv6 直连,公司端仍零安装、画质上限仍是 1080p120。
v5 路线定案
| 优先 | 路线 | 画质 | 卡点 |
|---|---|---|---|
| A(主攻) | 手机热点 + 家里 IPv6 直连 | 1080p120 满血 | ①热点下游能否拿到 IPv6 ②天翼网关是否放行 IPv6 入站 |
| A′(长期最优,当前失败) | 公网 IPv4 + 端口转发 | 1080p120 | 10000 申请被拒 |
| B | 腾讯云 frp 中继 | 1080p60(5 Mbps) | — |
| C | 网易UU远程 / ToDesk | 延迟 + 反作弊风险 | — |
代价认知:1080p120 @ 20 Mbps ≈ 9 GB/小时;5G 延迟预计 40–70 ms。
交付物
远程游戏串流方案_家到公司.md→ v5:新增 v4→v5 摘要、§1.3 重写(IPv6 地址稳定性分析)、§2 选型重排(路径 A 改为手机热点,原 A 降为 A′)、已排除表补入"IPv6 隧道类(6in4/Teredo/WARP)"、§7 重写为两步验证法hotspot-ipv6-test.ps1(新增,纯 ASCII / 无 BOM,已试跑通过,并复制到家里桌面C:\Users\xxl\Desktop\供 ToDesk 传输)—— 一次测完"热点下游有无 IPv6 + 能否连到家里"ipv6-home-qrcode.png(新增,扫码目标http://[240e:338:263:3600:29f1:e63f:d476:597e]:38443/)
本轮踩坑(重要,已沉淀)
& script.ps1调用脚本文件时,脚本内的写盘会静默失败 —— probe.ps1 / probe2.ps1 都返回 exit 0 却完全没生成结果文件;改内联命令 +Set-Content落盘立刻成功。→ 后续所有探测一律内联,不落脚本文件。Test-NetConnection对不可达的 IPv6 目标会长时间阻塞,把整个脚本拖到工具超时(第一次探测就是这样废掉的)→ 改用TcpClient.BeginConnect+AsyncWaitHandle.WaitOne(ms)实现硬超时。netsh/netstat的文本过滤会假阴性(netstat | ? { $_ -match ':38443' }报 NONE,实际Get-NetTCPConnection -LocalPort 38443显示:::38443 Listen)→ 查监听一律用Get-NetTCPConnection。
待用户执行(决定走哪条路)
- 手机 5G(关 WiFi)扫码访问家里
http://[240e:338:263:3600:29f1:e63f:d476:597e]:38443/→ 验证家里 IPv6 入站是否放行(此前失败,疑天翼网关拦入站) - 手机开热点 + 公司笔记本连上 → 跑
hotspot-ipv6-test.ps1→ 验证热点下游能否拿到 IPv6 并连通家里 - 若步骤 1 失败 → 按 §7 ② 放行天翼网关 IPv6 防火墙(或光猫改桥接)