03-Phase0侦察：写代码之前先确认这条路能不能走通
做远控项目最容易犯的一个错，是一上来就埋头写采集、写注入、写加密，写了三个月，最后发现公司电脑压根不让跑未签名 exe，或者公司防火墙把 443 以外的端口全堵死、直连根本出不去——前面所有工作全部白费。本项目把"先侦察、再动手"当成一条铁律，并给了它一个响亮的名字：Phase 0a 必须最先做。这篇就讲这套侦察哲学，以及我们实跑出来的结论。
一、推进哲学：Phase 0a 必须最先做
整个项目的推进被切成六个阶段，顺序是被严格规定死的：
Phase 0a 网络侦察：这条路能不能走通 Phase 0b 性能验证：采集/编码链路够不够快 Phase 1 只读远程画面 Phase 2 输入注入 + 保命措施 Phase 3 稳定性与交付（打包、自启） Phase 4 优化（剪贴板、代理、多显示器、P2P 等）为什么 0a 排第一？因为它成本最低、信息量最大。
- 成本最低：侦察工具只用 Python 标准库，不依赖任何第三方包，甚至能直接打包成几 MB 的小 exe，在公司电脑上双击就跑；
- 信息量最大：它一次性回答四个决定项目生死的问题——未签名程序能不能跑、能不能出网、哪个端口通、真实带宽多少。
反过来说：如果公司电脑的 EDR（终端防护）直接把未签名 exe 干掉，或者公司防火墙彻底封死出网，那么后面 Phase 1~4 哪怕写得再漂亮也毫无意义。先花半小时侦察，就能避免几个月的无用功，这笔账怎么算都划算。所以项目的顺序原则是铁律，不是建议。
二、侦察工具的 7 个步骤
项目源码里有一个纯标准库写的侦察工具（被控端侧），它连到 VPS 上另一个同样纯标准库的侦察服务端，依次做 7 件事：
| 步骤 | 测什么 | 为什么关键 |
|---|---|---|
| 1/7 | 本机环境（是否域环境、有无管理员权限） | 判断部署形态、权限边界 |
| 2/7 | 系统代理设置（IE 注册表 + WinHTTP + 环境变量） | 公司常要求经代理出网，得先摸清 |
| 3/7 | DNS 解析是否正常 | 连 IP 还是连域名，先确认能解析 |
| 4/7 | 能否访问知名 HTTPS 站点、TLS 是否被中间人解密 | 决定要不要钉扎证书、端到端加密是否足够 |
| 5/7 | VPS 的哪些端口能连通（每个端口同时测明文和 TLS） | 443 / 8443 / 80 / 8080 / 22 哪些放行 |
| 6/7 | 代理能否到达 VPS（HTTP CONNECT / SOCKS5，自动探测系统代理） | 直连不通时，代理兜不兜得住 |
| 7/7 | 真实吞吐量（上/下行各测 2 次） | 定压缩参数、判断够不够用 |
几个设计上的巧思值得说：
- 每个端口同时测"明文"和"TLS"两条通道。有些公司只拦明文、放行 TLS，或者反过来，分开测才知道真实情况。
- 第 4 步专门检测 TLS 中间人：它会记录服务端证书的签发者，如果发现证书被替换成公司代理的自签证书，就提示"疑似存在 TLS 中间人解密"。这直接决定了你两端要不要填
pinned_fingerprint——被中间人的话，钉扎反而连不上，但项目另有应用层端到端加密，留空依然安全。 - 第 6 步不只看状态行：它建完隧道后还会做一次真实往返。原因是实测发现，某些本地代理对"根本不可达的目标"也会先回
200 Connection established，之后才失败，只看状态行会给出假阳性——而假阳性比不检查更糟，它会让你误以为路通了。
三、结果三处留痕
侦察报告不会只打印在控制台上一闪而过。它三处同时留痕：
- 控制台：你当场就能看到结论；
- 本地文件：在机器上存一份
probe_result_<主机名>.txt，关掉窗口也还在； - 回传 VPS：把完整报告也发回侦察服务端，这样即使你本机窗口被关、文件没拷走，VPS 的日志里也有一份完整记录。
“三处留痕"是个很小的工程习惯，但很实用：你永远不用担心"报告看完了但没保存”“客户端没网传不回来”。任何一端有记录，结论就丢不了。
四、实测结论表（一次真实部署）
下面是本项目在一次真实部署中跑出来的 Phase 0a 结论（被控端是公司电脑、中继是境外 VPS）：
| 项 | 结果 |
|---|---|
| 未签名程序能否运行 | ✅ 能，EDR 未拦（最大风险点过关） |
| 443 端口 + TLS + 指纹匹配 | ✅ 可用，无中间人 |
| 8443 / 8080 | ❌ 公司防火墙超时 |
| 80 | ⚠️ 被 VPS 上别的服务占用，不可用 |
| 代理兜底 | ✅127.0.0.1:10808（本地混合入站代理）可到达 443 |
| 基础延迟 | ✅ ping 47~70 ms / TCP 握手 50~131 ms |
| 上行带宽 | ✅ 均值 19 Mbps，峰值 34.8 Mbps |
逐条解读一下它的决策价值：
- 未签名程序能跑：这是整张表里最该先确认的一行。它过了，后面才有的聊；它没过，项目直接转向"先解决签名/信任"或"此路不通"。
- 443 可用、8443/8080 超时、80 被占：直接锁定主用端口就是 443，回退链里 8443/8080 在公司网络下基本指望不上，所以连接顺序把 443 排最前。这也印证了"443 最易穿墙、最不显眼"的设计判断。
- 代理兜底可达：万一哪天直连被掐，还有
127.0.0.1:10808这条后路，把proxy指过去就能续命。 - 上行均值 19 Mbps、峰值 34.8 Mbps：这是定价带宽的关键依据——它说明"办公场景"完全够用，原分辨率 + 原生质量都吃得消，不用为了带宽去激进压缩。
五、吞吐量 > 2000 Mbps 是不合常理的
这里有一个反直觉的校验点：侦察工具测出来的吞吐量，如果显示大于 2000 Mbps，那一定是不合常理的，说明你测错了对象。
为什么？因为真实公网链路（尤其跨境）的带宽不可能这么离谱。出现这种数字，几乎只有一个原因：运行端和目标是同一台机器、或同一局域网，流量走了 loopback（回环），根本没出公网。
换句话说，你得对着真实的 VPS 公网 IP测，才有意义。如果你手滑填了127.0.0.1或localhost，或者 VPS 就在本地，测出来的"高带宽"是假的，据此定的压缩参数到了真实部署会直接翻车。所以项目在文档里专门把这条标红：见到来历不明的超高分，先怀疑是不是走了 loopback。
六、六阶段实施路线图与各自的验证数字
Phase 0a 确认"路通"之后，后面每一阶段都有明确的验证数字，确保不是"我觉得好了"，而是"测过了"：
| 阶段 | 内容 | 验证数字 |
|---|---|---|
| Phase 0a | 侦察 | 未签名可跑 ✅ / 443 可用 / 上行 19 Mbps |
| Phase 0b | 性能验证 | 采集 4.65 ms、差分 15.4 ms、单帧 29.7 ms（34 fps 上限）、办公带宽 0.54 Mbps |
| Phase 1 | 只读画面 | 中继+配对+加密 18/18；只读链路 12/12、4/4 |
| Phase 2 | 输入注入 | 注入链路 25/25、参数换算 46/46（dry-run） |
| Phase 3 | 稳定性与交付 | 打包自检通过、端到端跑通、反复重连 5 轮线程 4→1 全回收 |
| Phase 4 | 优化 | 剪贴板 25/25、代理 33/33、多显示器 26/26、真实公网 5/5 |
注意 Phase 0b 这一行：它在本机把"采集→缩放→差分→编码→解码"整条链路跑了一遍，得出单帧 29.7 ms（34 fps 上限），而目标只定 20 fps，余量充足；办公场景带宽中位只有 0.54 Mbps。这两个数字直接决定了target_width默认原生、max_fps默认 20 的取值——不是拍脑袋，是 Phase 0b 实测后定的。
这种"每个阶段都有量化验收"的做法，是项目能稳稳落地的底层原因。它把"做成"从一种感觉，变成了可以逐条打勾的清单。
七、侦察结论如何落到配置文件
侦察不是"跑完看个乐"，它每一条结论都要反推回你的config.toml。把第 4 节的实测结果翻译成配置，是这样的：
| 侦察结论 | 落到配置里就是 |
|---|---|
| 443 + TLS 可用、8443/8080 超时 | 连接顺序把 443 排最前；relay用wss://形式、端口 443 |
| 80 被占用 | 不用 80，避免和 VPS 上别的服务打架 |
代理127.0.0.1:10808可兜底 | 直连不通时proxy = "socks5://127.0.0.1:10808" |
| 无 TLS 中间人 | 可放心填pinned_fingerprint钉扎，防冒名中继 |
| 上行 19 Mbps、峰值 34.8 | target_width = 0（原生）、max_fps = 20，不必激进压缩 |
| ping 47~70 ms、跨境 | 预期有偶发尖峰，心里有数、不误判为故障 |
这张表的价值在于：配置不是凭感觉填的，是侦察数据一条条喂出来的。比如"为什么max_fps只定 20 而不是更高"——因为 Phase 0b 在本机测出单帧 29.7 ms（34 fps 上限），20 是留足余量后的值；“为什么target_width默认原生”——因为上行 19 Mbps 吃得起原生质量，降分辨率纯属浪费清晰度。你照着自己跑出来的侦察报告填，比抄别人的配置靠谱得多。
还有一个容易被忽略的点：侦察报告三处留痕（控制台 / 本地文件 / 回传 VPS），所以哪怕你当时没截图，VPS 日志里也有完整记录。部署时翻一眼回传的那份，比凭记忆填配置稳。
八、关于 P2P 的评估与暂缓决策
侦察和实测都做完之后，自然会想到一个问题：能不能让两端直接 P2P 打通，绕开 VPS 这多一跳？这样延迟和带宽就不再受自己 VPS 的限制。
项目对 P2P 做了评估，结论是暂缓，不现在做。理由很实在：
- UDP 打洞复杂度明显上升。如果一上来就做 P2P，Phase 1 就得先实现 NAT 穿透，工程难度陡增，会把"尽快跑通一个可用产品"的目标拖很久。
- 公司 NAT 可能打不通。公司网络的 NAT 类型不确定，UDP 打洞未必能成功，届时还是得回落中继——等于为一条可能走不通的路提前付了高成本。
- 中继先跑通更稳。先把"经 VPS 中继"这条最确定能走的路做扎实，P2P 留作 Phase 4 的可选优化，设计上已预留位置，但不阻塞主路径。
决策原则很清晰：先有可用的，再谈更优的。P2P 是"锦上添花"，不是"雪中送炭"，所以把它排到最后、且允许不做。这种"敢砍需求"的克制，恰恰是一个能真正交付的项目该有的样子。
小结
Phase 0a 侦察的本质，是用最小的成本去证伪"这条路走不通"。它成本低到只有一个标准库脚本，信息量大到能决定后面几个月往哪使劲。本项目把这个侦察环节当成不可跳过的前置铁律，并用"三处留痕"“loopback 异常检测”"代理要真往返"这些细节保证它测出来的是真相、不是假阳性。
记住一句话：写代码之前，先确认这条路能走通。能走通，再谈怎么走得好。
