邀请邮件投递与 SSH 连通排障｜Codex 日报 · 2026-06-24 · archx

按北京时间整理本机 archx 在 2026-06-24 的实际消息，共关联 3 条主会话。下文版本、路径和状态均对应当天记录。

邀请已提交，邮件卡在外部投递

较早的一次邮件检查请求中断，随后主会话成功登录服务器并检查 Vaultwarden 与 mailcow。Vaultwarden 的 SMTP 测试和邀请接口均返回 200；mailcow 接收了邮件，但队列仍有两封 deferred，原因是连接外部 Gmail MX 的 TCP 25 超时。

宿主机和 postfix 容器内测试都指向相同阶段。问题位于 mailcow 向外部 MX 的投递链路，而非邀请接口没有发出邮件。当天尚未完成收件箱投递，也没有实施解除出口限制或 SMTP relay 配置。

Vaultwarden 入口为 vault.envoys9.top。SMTP 当时通过 mailcow 的 587/STARTTLS 提交，凭据从 Vaultwarden 容器运行环境核对；这段记录未确认独立凭据文件路径，因此不补写一个猜测位置。

在邮件服务器检查队列和 relay 配置：

docker exec mailcow-dockerized-postfix-mailcow-1 postqueue -p
docker exec mailcow-dockerized-postfix-mailcow-1 postconf relayhost

队列输出可能包含收件地址，适合在服务器上查看。解除出口 TCP 25 限制、改用认证 relay 都只是当天提出的后续方案。

晚些时候 SSH 连接出现超时。Tailscale 显示节点在线， tailscale ping 经 DERP 有回包，但普通 SSH 和 Tailscale SSH 的 TCP 22 连接都未完成。调查停留在监听、防火墙、ACL 或转发层，尚未从服务器侧修复。

在 Arch 上排查时，替换为实际目标机器；历史记录使用 22 端口，不代表此后仍使用这个端口：

tailscale status
tailscale ping --timeout=5s --c 3 <目标节点>
ssh -vvv -o ConnectTimeout=10 -p <当前SSH端口> <用户>@<目标节点> true

~/.ssh/known_hosts 是服务器主机身份记录，不是登录私钥。当天证据没有确认使用哪个私钥文件，连接也尚未到达成功的用户认证阶段。

在本机 archx 终端执行：

工作目录： ~ 。

codex resume 019ef8ad-db84-7ad3-aa17-ed98254efc4e

工作目录： ~ 。

codex resume 019ef8b8-7e6f-7bb1-ac5f-c3e4de4f4057

工作目录： ~ 。

codex resume 019ef930-75f3-70e2-a1ea-6c24be501944