远程访问方案选型
远程操作一个串口设备有五条路径。它们解决的不是同一个问题，选错的代价通常是"连得上但改不了参数"或者"网络根本不通"。
- RFC 2217——把串口连同参数控制一起送到远端。客户端可以改波特率、校验位和 DTR/RTS。
- 透明 TCP 转发——只把字节从串口搬到网络。参数由现场那一端决定，远端改不了。
- Live Console（Web 远程调试）——通过云端中转，浏览器直接操作现场端口。不需要客户端能直达现场网络。
- Live Relay（远程串口）——通过云端中转，现场串口在另一台机器的软件里成为一个真正的端口，端到端跑 RFC 2217。网络前提与 Live Console 相同，但它是透明管道，不是实时窗口。
- Live Share（邀请码）——把上面那两条云端路径交给没有账号的同事：签一张有时限的码给他，他在浏览器里进来走的就是 Live Console，在自己的本软件里进来走的就是 Live Relay。技术上它复用那两条链路，选型上它是单独的一条：只有它不要求对方有账号。
这五条里的四条——RFC 2217 服务器、Live Console、Live Relay、Live Share——桌面端收在状态栏的 Live Sync（实时同步）入口下，一处点开。
各路径的拓扑差别
看图只看两处：箭头由哪一端发起，决定网络通不通；下方那条横线，决定远端能不能改串口参数。第五张图再多看一处：远端那一格里的人凭什么进来。
五者对比
| RFC 2217 | 透明 TCP 转发 | Live Console | Live Relay | Live Share | |
|---|---|---|---|---|---|
| 网络前提 | 客户端能直达现场 IP 和端口 | 客户端能直达现场 IP 和端口 | 现场能访问互联网即可，无需入站端口 | 现场能访问互联网即可，无需入站端口 | 同 Live Console / Live Relay |
| 远程修改串口参数 | 可以 | 不可以 | 可以 | 可以 | 在本软件里可以；浏览器里由签发时的等级决定 |
| 远程控制 DTR/RTS | 可以 | 不可以 | 可以 | 可以 | 只在本软件里 |
| 协议流（Modbus、文件传输、固件升级） | 可以 | 可以 | 不可以——限帧的实时窗口 | 可以 | 在本软件里可以，浏览器里不可以 |
| 客户端是什么 | 本软件、支持 RFC 2217 的虚拟串口、pyserial、设备管理软件 | 任意 TCP 程序 | 浏览器 | 本软件——登录同一账号 | 持邀请码的同事——浏览器或本软件，不需要账号 |
| 现场需要做什么 | 物理串口 + TCP Server + RFC 2217 服务端桥接 | 物理串口 + TCP Server + 透明桥接 | 登录账号并开启远程 | 登录账号并允许 Live Relay——图形界面或无界面的 spu --share |
登录账号并为某个已打开的串口签发邀请码——图形界面或无界面的 spu --invite |
| 加密与认证 | 无，依赖局域网或 VPN | 无，依赖局域网或 VPN | 有，走账号与云端链路 | 有，走账号与云端链路 | 有，走这张码与云端链路，口令可选 |
| 额外成本 | 无 | 无 | 占用流量配额 | 占用流量配额（Pro 额度更高） | 占用分享方的流量配额；访客不付费 |
| 配置入口 | RFC 2217 服务端 / RFC 2217 客户端 | TCP 与 UDP 调试 | Web 远程调试 | 远程串口 | 实时分享 |
怎么选
先回答第一个问题：客户端能不能直接访问现场的 IP 和端口？
- 不能（现场在 NAT 后面、没有公网地址、也没有 VPN）——只剩两条云端路径。为此在现场开放入站端口或做端口映射，是把一台调试机暴露到公网，代价远大于收益。接着问远端需要的是什么：
- 浏览器就够了——看数据、偶尔发条命令、开关端口——用 Live Console。
- 需要软件里的真端口——协议要端到端地跑（Modbus 轮询、XMODEM/YMODEM、固件升级），或者远端机器上的工具要独占这个口——用 Live Relay。
- 能，再问第二个问题：远端需要改串口参数吗？
- 需要改波特率、校验位、停止位或控制线——用 RFC 2217，两端都必须是 RFC 2217，只有一端是不行的。
- 只需要把字节搬过去，参数在现场就已经定好——用透明 TCP 转发，客户端可以是任意 TCP 程序，不必支持 RFC 2217。
两条云端路径还有第三个问题要问，它与网络无关：远端那个人有没有账号？
- 是你自己的另一台机器——两端登录同一个账号，直接用 Live Console 或 Live Relay，不必签码。
- 是别人，而且不该为一次协助去注册——用 Live Share 签一张邀请码，有效期 1 到 24 小时，用完即弃。他在浏览器里能做到哪一步由你在签发时决定；要跑协议、传文件、升级固件，就让他用这张码在自己的本软件里打开成真串口。
几个常见的错配：
- 现场桥接选了 透明转发，客户端却按 RFC 2217 连接——TCP 能建立，但不会出现"远端已接受串口参数设置"，参数下发全部无效。
- 客户端用普通 TCP Socket 连接一个 RFC 2217 服务端——协商字节会混进数据流，表现为开头几个字节是乱码。
- 在公网上直接暴露 RFC 2217 端口——它没有加密也没有认证，任何能连上的人都可以改你的串口参数。需要跨公网就用 VPN、Live Console 或 Live Relay。
- 试图用 Live Console 跑文件传输或 Modbus 轮询——它是限帧的实时窗口，不是管道，协议会卡死。这件事属于 Live Relay。
- 把 邀请码和口令写在同一条消息里发给同事——口令就白设了；码走一条消息，口令走另一条。
五条路径不互斥。现场常见的做法是：日常在局域网内用 RFC 2217，出差或跨地区时走云端——看用 Live Console，操作用 Live Relay，要拉同事进来就临时签一张 Live Share 的码——共用同一个物理串口连接。
端到端的完整配置示例，见 通过 RFC 2217 直连远端串口 和 随时随地通过 Web 调试串口。