使用frp穿透22端口后连接超时

Question

使用frp穿透22端口后连接超时，常见于服务器SSH服务响应缓慢或frp配置不当。典型问题为：客户端通过frp访问内网SSH时频繁出现“Connection timed out”，排查发现frp服务端（frps）与客户端（frpc）心跳间隔过长，且未启用健康检查机制，导致连接通道异常时未能及时重连。同时，防火墙或安全组若未放行frp通信端口，亦会引发超时。需合理设置 heartbeat_interval 与健康检测参数，并确保网络策略允许穿透流量通行。

Answer 1

1. 问题背景与现象描述

在使用 frp（Fast Reverse Proxy） 实现内网穿透以访问目标服务器的 SSH 服务（22端口）时，运维人员常遇到“Connection timed out”的问题。该现象表现为客户端通过 frp 客户端（frpc）连接远程 SSH 服务时，长时间无响应或直接超时中断。

典型场景包括：开发人员尝试从公网连接位于 NAT 后的开发机、自动化脚本无法稳定拉取日志服务器数据等。初步排查通常排除本地网络问题后，焦点集中于 frp 架构中的通信稳定性与网络策略配置。

2. 常见原因分析：由浅入深

• 网络层阻断：防火墙、安全组未开放 frps 监听端口（如 7000）或 frpc 回连端口。
• SSH 服务本身响应慢：目标主机负载高、sshd 配置不当或密钥认证延迟。
• frp 心跳机制缺失：默认心跳间隔过长（如 30s），链路异常时不能及时感知。
• 健康检查未启用：frpc-frps 连接中断后未能自动重连，通道处于假死状态。
• 协议兼容性问题：TCP 长连接在中间 NAT 设备上被主动回收。

3. 核心配置项解析与优化建议

配置参数	默认值	推荐值	作用说明
heartbeat_interval	30	10	降低心跳间隔可更快检测链路故障
heartbeat_timeout	90	30	避免因超时间隙过大导致重连滞后
health_check_type	-	tcp	开启 TCP 层健康检查，主动探测后端服务
health_check_interval_s	-	5	每 5 秒检查一次 SSH 是否存活
health_check_max_failed	-	3	连续失败 3 次则触发重连机制

4. 关键配置代码示例

[common]
server_addr = your-frps-public-ip
server_port = 7000

# 缩短心跳周期，提升链路敏感度
heartbeat_interval = 10
heartbeat_timeout = 30

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 6000

# 启用健康检查机制
health_check_type = tcp
health_check_interval_s = 5
health_check_max_failed = 3
health_check_timeout_s = 3

5. 网络策略与安全组验证流程

1. 确认 frps 所在服务器的安全组/iptables 允许入站流量通过 7000（控制端口）和 6000（映射端口）。
2. 检查 frpc 端出口是否受限，可通过 telnet 测试连通性：
   telnet your-frps-ip 7000
3. 使用 tcpdump 抓包分析 frpc 是否成功建立初始连接：

4. tcpdump -i any host <frps_ip> and port 7000

5. 观察 frps 日志中是否有 client register 成功记录。
6. 若使用云服务商（如阿里云、AWS），需额外检查 VPC 路由表及 NACL 规则。

6. 故障诊断流程图（Mermaid）

graph TD
    A[SSH连接超时] --> B{能否直连内网SSH?}
    B -- 是 --> C[检查frp配置]
    B -- 否 --> D[排查目标SSH服务]
    C --> E[查看frpc/frps日志]
    E --> F[是否存在心跳超时错误?]
    F -- 是 --> G[调整heartbeat_interval和timeout]
    F -- 否 --> H[检查health check是否启用]
    H -- 否 --> I[启用TCP健康检查]
    I --> J[重启frpc并监控状态]
    J --> K[测试连接恢复情况]

7. 高级调优建议与生产实践

对于企业级部署，建议结合以下措施增强稳定性：

• 部署多个 frps 实例配合 DNS 轮询或 SLB 实现高可用。
• 启用 frps 的 TLS 认证模式防止中间人攻击。
• 使用 systemd 或 supervisord 守护 frpc 进程，防止崩溃后失联。
• 定期采集 frp metrics（通过 Prometheus 插件）监控连接数、带宽、延迟趋势。
• 对关键业务 SSH 节点设置独立的 proxy 配置，避免资源争抢。