这次遇到了两个连续的问题：原端口突然无法连接；换端口后远程连接恢复，但 RustDesk 设备列表显示离线，CortenDesk 后台却显示在线。
最终确认：设备列表状态异常是遗漏了配套的在线查询端口映射。原端口连接异常则有网络重置的证据，但没有确认具体来源。本文记录本次 Docker 部署环境中的排查过程，示例中的 SERVER_IP 请替换为实际服务器地址。
一、原端口突然无法连接
客户端报错：
WebRTC failed: Failed to connect to SERVER_IP:21116;
fallback failed: Failed to connect to SERVER_IP:21116Windows 使用 PowerShell 检测：
Test-NetConnection SERVER_IP -Port 21116结果是 Ping 正常、TCP 连接失败，而同一服务器的 21115 可以连接。Ping 成功只能证明 ICMP 可达，不代表对应 TCP 端口可用。
在服务器检查监听、容器和防火墙：
sudo ss -lntup | grep 21116
docker ps -a
docker port cortendesk
sudo iptables-save -c
sudo nft list ruleset- 容器运行正常，21116 的 TCP、UDP 均有映射。
- 防火墙存在明确的放行和转发规则。
- 大量拒绝规则只针对 SSH 22 端口，与本次故障无关。
- 没有发现针对 21116 的 TCP 重置规则。
注意：docker-proxy 正在监听、容器显示 healthy，都不能单独证明完整的 RustDesk 通信正常；需要结合抓包和实际连接结果判断。
二、抓包定位连接重置
sudo tcpdump -ni eth0 -nn 'tcp port 21116'保持抓包运行，在客户端重新执行端口测试，结束后按 Ctrl+C。eth0 应按服务器实际网卡名称调整。
观察到的顺序是：客户端 SYN 到达服务器，转发进入容器；容器回复 SYN-ACK，并从服务器网卡发出；随后 RST 从外部网卡进入，握手没有正常完成。
换用其他公网端口后，同一服务可以连接。因此怀疑原 IP＋端口的网络路径存在过滤或重置。但单侧抓包不能确定是运营商、云平台还是其他中间设备，也不能把报文中的来源 IP 直接当成真实发送者。要进一步归因，需要客户端与服务器双端抓包，或者由云厂商核查防护事件。
三、换端口后能连接，但设备列表显示离线
将公网 ID 端口改为 35210 后，最初的相关映射如下：
ports:
- "21115:21115/tcp"
- "35210:21116/tcp"
- "35210:21116/udp"
- "21117:21117/tcp"此时远程连接可用，CortenDesk 后台显示在线，但 RustDesk 客户端设备列表的状态异常，而且所有设备都有这个现象。
继续检查 UDP：
sudo tcpdump -ni eth0 -nn 'udp port 35210'可以看到客户端周期性发送数据，服务器也有回复。结合后台在线及实际连接正常，排查重点转向设备列表的在线状态查询。
关键在于：本次使用的 RustDesk 客户端会通过“ID 服务器端口减 1”的 TCP 端口查询设备在线状态。配置的 ID 端口是 35210，客户端便会访问 35209；只保留公网 21115，无法满足这一查询。
四、最终修复配置
在现有 Compose 服务的 ports 下增加：
- "35209:21115/tcp"最终相关映射如下。这里只展示端口部分，应合并到原有配置中，保留其他业务端口、数据卷和环境变量：
ports:
- "35209:21115/tcp"
- "35210:21116/tcp"
- "35210:21116/udp"
- "21117:21117/tcp"| 公网端口 | 容器端口 | 用途 |
|---|---|---|
| TCP 35209 | TCP 21115 | 在线状态查询、NAT 检测 |
| TCP＋UDP 35210 | TCP＋UDP 21116 | ID 注册、心跳及连接协调 |
| TCP 21117 | TCP 21117 | 中继连接 |
云防火墙及启用的系统防火墙同步放行对应协议和端口。在 Compose 文件目录执行：
docker compose up -d应用端口修改可能重建容器，导致服务短暂中断。然后从 Windows 验证：
Test-NetConnection SERVER_IP -Port 35209
Test-NetConnection SERVER_IP -Port 35210这些命令只检测 TCP，不能验证 UDP。补齐 TCP 35209 映射并放行后，重新打开 RustDesk 设备列表，在线状态恢复正常，实际验证修复有效。
五、Debian 客户端通过命令修改
对于支持 –option 的已安装客户端，保持 RustDesk 服务运行，以管理员权限设置 ID 服务器：
sudo rustdesk --option custom-rendezvous-server SERVER_IP:35210读取配置确认：
sudo rustdesk --option custom-rendezvous-server本次中继公网端口仍为 21117，因此显式设置：
sudo rustdesk --option relay-server SERVER_IP:21117如果服务此前已停止，先启动再执行配置命令：
sudo systemctl start rustdeskSERVER_IP 替换为实际服务器地址，Key 保持原值。控制端与被控端都应使用正确的 ID 服务器配置；如果中继端口另外调整，也要同步更新中继地址。
六、这次排查的经验
- 修改 ID 公网端口为 P 时，同时考虑 TCP P−1，并将它映射到容器 21115。
- 公网映射端口与容器内部端口不必相同，但客户端推导的关联端口必须对应。
- 能够远程连接、后台显示在线、客户端列表显示在线，是不同的检查结果，不能互相替代。
- 原端口异常和改端口后的列表状态异常是两个问题：前者尚未确认具体干预来源，后者已通过补齐端口映射修复。
参考：RustDesk 自建服务器文档；RustDesk 客户端源码（peer_online / create_online_stream）。不同版本或定制服务端可能存在差异，应以所用版本和实际验证结果为准。