常见连通性排查需先验证基础网络：用nc -zv测frps bind_port是否可达，不通则查防火墙、安全组或dns；再确认frps进程运行、auth_token一致、server_addr可解析、bind_port监听0.0.0.0、http穿透时域名a记录指向frps公网ip且vhost端口未被占用。
frp 客户端连不上服务端的常见连通性排查
内网穿透失败，八成卡在基础网络连通或 frp 配置错位。别急着改配置，先确认最底层能不能通。
- 用
telnet或nc -zv直接测服务端bind_port（如7000）是否可访问：客户端执行nc -zv your-frps-domain.com 7000，不通就不是 frp 的问题，是防火墙、云厂商安全组或 DNS 解析问题 -
frpc日志里出现dial tcp: i/o timeout或connection refused，优先查服务端进程是否真在跑：ps aux | grep frps+netstat -tlnp | grep :7000 - 服务端开了
auth_token，但客户端配置里写错了或漏了——这个字段必须严格一致，大小写、空格、换行都算错
frp 配置中 server_addr 和 server_port 的实际含义
这两个参数决定 frpc 怎么找到 frps，但很多人按“域名+端口”直觉填，结果连不上。
-
server_addr是 frpc 发起 TCP 连接的目标 IP 或域名，**不走 HTTP 代理，不解析为内网地址**；如果填了内网 DNS 域名（比如frps.internal），而客户端机器没配该 DNS，就会解析失败 -
server_port对应 frps 的bind_port，不是vhost_http_port或vhost_https_port；填错会导致连接建立阶段失败，日志里看不到任何隧道相关提示 - 云服务器上部署 frps 时，
bind_port必须监听0.0.0.0，不能只绑127.0.0.1；否则外网客户端根本连不进来
HTTP 类型穿透下 custom_domains 不生效的典型原因
配好了 type = http，也写了 custom_domains = example.com，但浏览器访问 502 或直接超时，大概率是域名或服务端配置没对齐。
- 域名 A 记录必须指向 frps 所在服务器的公网 IP，不是内网穿透客户端的 IP；frps 收到请求后，才根据
custom_domains转发给对应local_port - frps 配置里
vhost_http_port默认是80，如果被 nginx 占了，要么改它，要么在 frps 里显式设成其他端口（如8080），并确保该端口在安全组放行 - frpc 的
local_port指向的是内网服务的真实端口，比如你本地起了一个python3 -m http.server 8000，那这里就得填8000，不是80
长期运行时 frp 进程意外退出的运维盲点
frp 不是 systemd 原生服务，裸跑容易因 OOM、信号中断或日志满盘而静默退出，监控和重启机制得自己补。
- 别用
nohup frpc -c xxx &启动——没有进程守护，父 shell 退出后子进程可能被 SIGHUP 杀掉；改用systemd或supervisord - frpc 日志默认输出到 stdout，不落盘；加
log_file = ./frpc.log和log_level = info，否则出问题时连最近一次连接尝试都查不到 - 内网机器内存小、frp 版本旧（如 v0.34 以下）时，长时间运行可能出现 goroutine 泄漏，表现为 CPU 持续爬升、连接数不增但延迟变高；建议用 v0.50+ 并定期 reload
frp 看似简单，但每个环节都依赖底层网络、权限、时序的精确配合；配置写对只是起点，真正难的是让它的状态可观察、故障可归因。
