最近把一个旧服务器的 CPA/CPAMP 服务完整迁移到了新的服务器。Docker Compose、Caddy、HTTPS、历史数据和插件都已经验证正常，API 也可以正常调用。
服务器迁移完成以后，我准备通过 SSH 继续维护旧服务器，却遇到了一个很奇怪的问题：SSH 有时直接提示连接被关闭，有时提示 Permission denied (publickey)。更奇怪的是，显式指定另一把私钥后，连接似乎又成功了。
后来我发现，问题并不是服务器突然忘记了公钥，也不是 CPA 或 Caddy 的配置错误，而是本地 FlClash 核心异常后，SSH 流量走到了错误的路径。
诡异的错误提示
最开始看到的是：
Connection closed by <SERVER_IP> port <SSH_PORT>Permission denied (publickey)这两条信息很容易把排查方向转向到服务器端：检查安全组、检查 SSH 服务、检查 authorized_keys。
但 SSH 的认证错误有一个前提：客户端必须先连接到了正确的服务器。如果连接目标本身就错了，那么服务器返回的认证错误没有分析价值。此时继续修改密钥，只是在错误的机器上重复尝试。
因此，第一步应该是确认服务器身份。
先检查别名最终使用的地址和端口：
ssh -G <ALIAS>再使用详细模式连接：
ssh -vvv <ALIAS>重点看三个信息：
- 最终连接的 IP 地址；
- 最终连接的端口；
- 服务器发送的 SSH 主机指纹。
为什么监控网站还是正常的
排查过程中，监控面板和普通网站都可以打开，所以我一度以为服务器网络没有问题。
其实这两个结论并不矛盾。浏览器访问网站通常经过域名解析、HTTPS 和浏览器代理；SSH 别名可能直接连接一个固定 IP 和自定义端口。它们经过的 DNS、规则匹配、代理模式和路由路径都可能不同。
用另一条路径确认问题在哪里
我随后从另一台可以正常连接的服务器发起跳转，使用旧服务器对应的密钥和端口连接。通过跳板机访问时，看到的是旧服务器真实的主机信息，SSH 服务本身也能正常接受密钥。
| 检查对象 | 结果 | 结论 |
|---|---|---|
| 服务器 SSH 服务 | 正常 | 不是 sshd 故障 |
| 服务器公钥认证 | 通过跳板机正常 | 不是 authorized_keys 丢失 |
| DNS 解析 | 指向预期地址 | DNS 不是主要原因 |
| 浏览器监控页面 | 正常 | Web 路径仍可用 |
| 本地直连 SSH | 指纹和预期不一致 | 本地连接路径异常 |
FlClash 核心异常的证据
我导出了 FlClash 的日志。日志中多次出现下面的前端错误：
IPC error: read error: failed to fill whole bufferIPC Disconnected这表示 FlClash 前端与核心之间的 IPC 通道没有读完一条完整消息就断开了。能够证明前端与核心之间发生过异常断连。
时间线也能和网络现象对应起来：
- IPC 断开时，多条 IP 检查请求同时出现 TLS handshake 失败或连接未收完响应头；
- 核心重新连接后，IP 检查又恢复成功；
- 手动重启 FlClash 核心后，SSH 和 HTTPS 连接也恢复正常。
已确认的事实是：FlClash 前端记录到了 IPC 断开，SSH 的实际连接身份异常，并且重启核心后恢复。
尚未确认的是：核心为什么会进入这个状态，以及 TUN 内部具体哪一步没有正确重建。原始故障发生时没能提前保存完整的核心实时流，因此根因没有确定。
最终修复：重启核心
直接重启 FlClash 核心后，问题恢复了。这个动作会让当前核心重新建立 IPC、TUN 和运行时网络状态，清理掉本次异常留下的临时状态。
重启以后：
- SSH 服务器主机指纹恢复为预期值；
- 使用正确的私钥可以完成认证；
- HTTPS 请求不再出现握手阶段被重置；
- CPA/CPAMP 服务继续正常运行；
- 没有因为排查而修改历史数据或服务器端密钥。
结语
这次故障最容易误导人的地方，是错误看起来非常像 SSH 密钥失效：先是连接被关闭，然后又出现公钥拒绝（当时真以为服务器被盗了）。最后才发现真正的问题是虚拟网卡导致的ip转发（？）错误，正常很难发现。以后遇到问题得先重启核心了。（下次再遇到再补充，目前还是不知道具体核心发生了什么）