Chevnia Blog

Appearance

autossh 常见故障排查 ​

这份文档用于排查 autossh 本地 1080 SOCKS 代理相关问题。

适用场景：

  • 服务看起来启动了，但代理不能用
  • 1080 端口没有监听
  • 开机后没有自动拉起
  • 日志里有报错
  • 想快速判断问题出在本机、SSH、远端还是 launchctl

1. 先做最小检查 ​

先按下面顺序检查：

bash
autossh-status
autossh-log
curl --socks5 127.0.0.1:1080 https://ifconfig.me

可以这样理解：

  • autossh-status：看服务和端口是否存在
  • autossh-log：看有没有直接报错
  • curl --socks5 ...：验证代理是否真的可用

2. 常见现象与对应判断 ​

现象 0：autossh-log 里反复出现 port 22: Operation timed out ​

典型日志：

text
ssh: connect to host 100.x.x.x port 22: Operation timed out

这类现象不一定是 autossh 自己坏了，也不一定是远端 sshd 没开。

这次实际排查里，最终定位到的真实原因是：

  • 远端机器 hf-air 的 sshd 正常监听 22
  • tailscale ping 100.x.x.x 正常
  • 但 ssh your_user@100.x.x.x 超时
  • mini 上抓包能看到发往 100.x.x.x:22 的 SYN
  • hf-air 上抓包却看不到对应 22 端口流量
  • 最终发现是 Tailscale grants 只加了 relay 能力，没有补普通网络层访问授权

也就是说：

  • autossh 失败只是表象
  • 真正的问题在 Tailscale Access Controls 策略

这种情况下，优先检查：

bash
tailscale ping 100.x.x.x
ssh -o ConnectTimeout=5 your_user@100.x.x.x
nc -vz 100.x.x.x 22

如果出现下面这种组合：

  • tailscale ping 通
  • ssh/nc 不通
  • 远端确认 22 在监听

就要高度怀疑：

  • Tailscale grants / ACL 问题
  • 尤其是最近刚改过 peer relay / Access Controls

这次最终的修复方式是，在 Tailscale policy 里补上网络层访问：

json
{
  "src": ["autogroup:member"],
  "dst": ["autogroup:member"],
  "ip": ["*"]
}

如果你只想恢复 SSH，也可以只开：

json
{
  "src": ["autogroup:member"],
  "dst": ["autogroup:member"],
  "ip": ["tcp:22"]
}

现象 1：launchctl list | grep autossh 有结果，但 1080 没监听 ​

重点检查：

bash
autossh-log

常见原因：

  • plist 中 autossh 路径写错了
  • 远端用户名写错了
  • SSH 连接失败
  • 端口转发失败

建议检查：

bash
which autossh

确认 plist 中的路径是否和实际一致。

再手动执行一次命令，看是否能直接报错：

bash
autossh -M 0 -N -D 1080 \
  -o "ServerAliveInterval 30" \
  -o "ServerAliveCountMax 3" \
  -o "ExitOnForwardFailure yes" \
  your_user@100.x.x.x

注意这里为了排查，故意不加 -f，方便直接看输出。

现象 2：1080 在监听，但代理不能正常访问网站 ​

先测：

bash
curl --socks5 127.0.0.1:1080 https://ifconfig.me

如果失败，常见原因：

  • SSH 隧道虽然建立，但远端出网异常
  • 远端机器网络受限
  • DNS 或目标站点访问受限

可以进一步测试 SSH 是否本身正常：

bash
ssh your_user@100.x.x.x

如果 SSH 登录都不稳定，优先排查远端连通性。

现象 3：开机后没有自动启动 ​

先看服务状态：

bash
launchctl print gui/$(id -u)/com.autossh.socks1080

再看日志：

bash
autossh-log

常见原因：

  • plist 没有正确加载
  • autoload 前提不满足
  • SSH 需要密码或交互确认
  • 免密登录没有配置好

建议重点确认免密登录：

bash
ssh your_user@100.x.x.x

如果这里还要求输入密码，那开机自启通常不稳。

现象 4：日志里是空的，但仍然感觉服务不正常 ​

这通常说明：

  • 没有明显程序级错误
  • 但不代表代理一定可用

这时不要只看日志，直接做网络验证：

bash
curl --socks5 127.0.0.1:1080 https://ifconfig.me

再看端口：

bash
lsof -i :1080

只要 curl 失败，就继续从 SSH 连通性和远端网络排查。

现象 5：launchctl bootstrap 报“service already loaded” ​

说明服务已经在运行或已加载。

处理方式：

bash
autossh-stop
autossh-start

或者直接：

bash
autossh-reload

现象 6：autossh-stop 后服务似乎还在 ​

先检查是不是旧进程残留：

bash
lsof -i :1080
ps aux | grep '[a]utossh\|[s]sh.*1080'

如果发现有手工启动的 ssh/autossh 进程，它可能不受当前 launchctl 这份 plist 管理。

这种情况说明之前可能同时用了：

  • 手动后台命令
  • launchd 托管命令

建议统一只保留一种方式，通常保留 launchd 托管更合适。

3. 推荐排查顺序 ​

如果出现问题，建议按这个顺序查：

  1. 看服务是否存在
bash
autossh-status
  1. 看错误日志
bash
autossh-log
  1. 看端口是否监听
bash
lsof -i :1080
  1. 测代理是否真的能用
bash
curl --socks5 127.0.0.1:1080 https://ifconfig.me
  1. 测普通 SSH 是否正常
bash
ssh your_user@100.x.x.x
  1. 确认 plist 路径和 autossh 路径是否正确
bash
which autossh

4. 常见修复动作 ​

重载服务 ​

bash
autossh-reload

先停再启 ​

bash
autossh-stop
autossh-start

实时看日志 ​

bash
autossh-log-follow

手工前台测试 ​

bash
autossh -M 0 -N -D 1080 \
  -o "ServerAliveInterval 30" \
  -o "ServerAliveCountMax 3" \
  -o "ExitOnForwardFailure yes" \
  your_user@100.x.x.x

5. 最重要的几个结论 ​

  • 1080 在监听，不代表代理一定能出网，还要用 curl --socks5 测一下
  • 日志为空，不代表 100% 正常，只能说明没有明显报错
  • 开机自启最常见的问题是 SSH 免密没配好
  • 旧命令启动的服务，也可以直接用新命令停止和重载
  • 真遇到问题时，最有效的排查方式通常是“前台运行一次，不加 -f”
  • 如果日志里是 port 22: Operation timed out，而远端又确认 SSH 正常，记得把 Tailscale grants / ACL 也纳入排查范围