凌晨一点半frpc 的日志里滚出第三十条login to server failed: EOF服务端那台机器的日志却干干净净一个字符都没多。这个场面我太熟了——frp 客户端明明能连上端口可登录握手在第一步就被人从中间掐断客户端什么响应都拿不到只能把对端把连接关了这件事翻译成一个干巴巴的 EOF。标题里那三个词本质上是同一个问题的三个面工具是 frp现象是客户端登录服务端时报 EOF环境是校园网这类出口管得比较严的网络。先把边界说清楚这篇文章不聊任何绕过或破解的事只解决一个技术问题——你自己搭的 frp 穿透通道为什么会在登录阶段失败以及怎么一层层查出来、修好顺手把一整套可复现的搭建流程补齐。适合两类人一类是把家里的 NAS、树莓派、开发机上的 Web 服务通过 frp 暴露出去做远程访问的另一类是在宿舍网、实验室网络、办公网这类出口策略比较复杂的链路里跑 frp 长连接频繁看到断线重连报错的。哪怕你之前只用过带图形界面的托管穿透客户端、从没手写过配置文件下面的排查链路一样能照着走。1. 从一串 EOF 日志说起这个报错到底卡在哪一步很多人第一次看到login server failed eof第一反应是是不是我网断了。恰恰相反能报出 EOF说明你的网络没断。EOF 是应用层读到一个连接被正常关闭的信号前提是这条 TCP 连接曾经建立成功过。如果网络根本不通你看到的会是i/o timeout、connection refused或者no route to host那是另一套排查逻辑。所以第一条重要认知EOF 属于连上了但被拒绝这一类故障范围一下子缩小了很多。我见过最典型的误判是把 EOF 当成 token 写错了。token 错是不会给你 EOF 的服务端会老老实实回一条认证失败的消息客户端日志里写的是authentication failed或者token in login doesnt match token from configuration。这两条日志的区别就是排查方向的分水岭后面我会专门拿一节来讲。1.1 frpc 的登录流程TCP 只是入场券EOF 发生在验票口把 frp 的启动过程拆成两段事情就清楚了。第一段是网络层frpc 向serverAddr:serverPort默认 7000发起 TCP 三次握手这一段只关心包能不能来回。第二段是应用层连接建好后frpc 发出一条Login消息里面带着版本号、主机名、操作系统、架构、时间戳和认证信息然后安静地等LoginResp。只有收到LoginResp客户端才会打印login to server success接着开始注册隧道。EOF 就发生在第二段。TCP 已经握手成功frpc 把Login发出去了但还没等到回应连接就被关了。可能是服务端进程自己关了可能是服务端前面的某台设备关了也可能是客户端出口的某台设备关了。frpc 作为被动方没有任何办法区分这三种情况它只能统一报 EOF。想让 frpc 告诉你真相得靠你自己去两端各自取证。1.2 为什么 frpc 只丢给你一个 EOF 就闭口不言这里有个很多人没意识到的细节frp 的协议是客户端先说话的。frpc 连上后不会等服务端打招呼而是立刻把Login推过去。这意味着如果 7000 端口上坐着的根本不是 frps——比如你把端口写成了 443对面是 Nginx或者域名解析被改写对面是运营商的错误页服务器——那对面收到一堆二进制垃圾通常会直接把连接关掉或者回一个 HTMLfrpc 读到的依然是一个 EOF。还有一种情况是 TLS 层出问题。frp 支持在传输层外面套一层 TLS服务端如果开了transport.tls.force true就意味着我只接受 TLS 连接。此时一个没开 TLS 的客户端连上来服务端在 TLS 握手阶段就直接把连接掐了客户端看到的还是 EOF。报错位置和真实原因之间隔了两层这就是为什么光看客户端日志永远猜不准。1.3 三种失败节奏秒断、握手后断、重连时偶发同样是 EOF出现的时机不同指向的原因差得很远。我一般按距离 TCP 建连成功过了多久来分类现象时间特征大概率原因秒断式 EOF建连后 0~1 秒即断TLS 配置不匹配、端口指向了非 frps 进程、出口设备直接发 RST停顿几秒后 EOF建连后 3~30 秒断开出口会话老化、中间设备回收空闲连接、服务端进程被拉起又被杀重连时偶发 EOF运行一段时间后重连才出现多出口源地址漂移、DNS 轮询到坏地址、服务端负载或内存问题秒断式最常见也最好修翻一下两端的 TLS 配置基本就定位了。偶发式的 EOF 最磨人因为它不影响功能只是隔几小时给你来一次断连很多时候用户根本不会注意到直到某天发现隧道悄悄没了。判断节奏的办法很简单看 frpc 日志的时间戳从start frpc到login to server failed中间隔了多少秒。2. 拆开 7000 端口上的对话frp 登录握手里藏着哪些开关想定位 EOF得先知道这条连接上到底跑了什么。frp 的控制连接其实很朴素就是一条 TCP或者 KCP、QUIC上面按顺序跑三样东西可选的 TLS、frp 自己的消息帧、以及之后的心跳。搞混这三层的人特别多经常出现我明明开了 TLS 怎么还报 EOF这种问题——因为开着 TLS 和两边都开着 TLS 是两回事。2.1 一次完整登录的报文顺序正常流程是这样的TCP 三次握手完成如果配置了 TLS 就做 TLS 握手并校验证书然后 frpc 发送Login服务端校验认证信息回LoginResp客户端打印login to server success紧接着开始为每个[[proxies]]建立工作连接、注册隧道最后进入心跳维持阶段。关键点在于认证检查发生在Login之后而 TLS 检查发生在Login之前。也就是说TLS 不匹配导致的失败连消息帧都还没开始解析服务端日志里可能一条记录都没有而 token 不匹配服务端日志里一定有一条明确的拒绝记录。这个先后顺序决定了你该去翻客户端日志还是服务端日志。2.2 token、TLS、多路复用各自负责哪一段把这三个东西各管什么说清楚排错会快很多。token管的是你是不是我认可的人在 frp 消息层校验错了给authentication failed。TLS管的是这条链路是不是加密的、证书对不对在 TCP 之上、frp 消息之下不对给 EOF 或 x509 相关报错。多路复用tcpMux默认开启管的是多条隧道能不能共用一条 TCP。它开着的时候所有隧道共享同一条控制连接好处是省资源、穿透更顺畅代价是这条连接一断你所有隧道一起断日志会同时刷出好几条错误看着像全线崩溃其实是一个故障点。排查时如果有这种同时全灭的现象优先怀疑控制连接而不是逐个隧道去查。2.3 EOF 和 authentication failed 为什么必须分清我把这两个报错做成一张对照表贴在笔记里用了两年省下的时间比读十篇教程都多客户端日志说明协议走到了哪该查什么login to server failed: EOF服务端在LoginResp之前就关了连接TLS 配置、端口对不对、中间链路、服务端进程authentication failed协议正常认证被拒两端 token 是否一致、是否有空格或不可见字符i/o timeout连接压根没建起来安全组、防火墙、地址是否可达connection refused对端端口没人监听服务端进程是否在跑、监听端口是否一致port not allowed协议正常端口超出白名单服务端allowPorts范围看表的顺序就是排查的顺序从上到下问题越来越靠应用层。EOF 排在最上面因为它最靠底层也最难靠日志自查。3. 搭一套自己能完全掌控的最小 frp 环境排查 EOF 最快的方式从来不是在网上搜EOF 是什么意思而是搭一套两端都由自己掌控的环境。托管服务出问题时你拿不到服务端日志只能靠猜自建之后服务端日志就是你的显微镜。这一节给一套我线上在用的最小配置版本以 0.52 之后的 TOML 格式为准0.52 开始 INI 格式已经弃用还在用.ini的建议尽快迁移。3.1 服务端frps.toml 里真正不能错的几个值服务端需要一台带公网 IP 的机器。除了 frp 本身还要记得在系统防火墙和云平台安全组里放行两个东西bindPort默认 7000控制连接用和你要暴露出去的remotePort段。bindPort 7000 auth.method token auth.token 换成你自己的32位以上随机串 transport.tls.force true transport.heartbeatTimeout 90 transport.tcpMux true allowPorts [ { start 2000, end 2010 } ] log.to /var/log/frps.log log.level info log.maxDays 7这里每一个值都有理由不是照抄教程抄来的。transport.tls.force true是为了让控制连接强制走 TLS避免认证信息裸奔代价是你所有客户端都必须开 TLS否则必然 EOF——这也是我在无数帖子里看到的最常见坑。allowPorts是给自己上的一道锁万一 token 泄漏别人也只能占用 2000 到 2010 这几个端口不至于把你的公网端口扫个遍。heartbeatTimeout 90表示服务端 90 秒没收到客户端心跳就判定掉线这个值在出口会话老化比较快的网络里要往下调。3.2 客户端frpc.toml 的最小可用模板客户端配置比服务端长一些但真正影响登录成功率的就是前几行。serverAddr 你的公网IP serverPort 7000 loginFailExit false auth.method token auth.token 和服务端完全一致 transport.tls.enable true transport.heartbeatInterval 15 transport.dialServerTimeout 10 log.to /var/log/frpc.log log.level info log.maxDays 3 webServer.addr 127.0.0.1 webServer.port 7400 webServer.user admin webServer.password 自己设一个 [[proxies]] name ssh-home type tcp localIP 127.0.0.1 localPort 22 remotePort 2001 [[proxies]] name web-home type tcp localIP 127.0.0.1 localPort 8080 remotePort 2002loginFailExit false是个容易被忽略但很实用的开关。默认情况下登录失败达到一定次数frpc 会直接退出进程设成 false 之后它会一直重试配合 systemd 的自动重启在网络抖动的环境里体验会好很多。transport.tls.enable true必须和服务端的force对上要么两边都开要么两边都不开单边开就是秒断 EOF。3.3 用 systemd 托管别让连接的生死跟着 SSH 走很多人习惯 SSH 上去之后敲一句./frpc -c frpc.toml然后把终端挂在那儿。SSH 一断或者终端一关frpc 跟着一起走日志断在半截之后看到的现象就是隧道莫名其妙没了。正确做法是交给 systemd[Unit] Descriptionfrp client Afternetwork-online.target [Service] Typesimple Restartalways RestartSec5 ExecStart/usr/local/bin/frpc -c /etc/frp/frpc.toml [Install] WantedBymulti-user.targetRestartalways加上RestartSec5配合loginFailExit false基本可以把网络抽风导致的短暂断开这个因素从你的故障清单里划掉。另外提一句frpc 转发本地 1024 以下的端口并不需要 root 权限只有监听低位端口才需要所以别图省事用 root 跑它。3.4 上线前的四步自检顺序我在每次换机器、换网络环境之后都会走一遍这四步顺序不能颠倒解析dig short 你的域名确认解析出来的 IP 跟你预期一致别被本地 DNS 带偏。连通nc -vz -w 3 你的公网IP 7000只验证 TCP 层能不能通。语法frpc verify -c /etc/frp/frpc.toml老版本用frpc -t -c配置写错这一步就能拦住不用等到运行时报一堆莫名其妙的错。前台跑一次手动执行frpc -c /etc/frp/frpc.toml把完整日志看一遍确认出现login to server success再去服务端日志里找对应的登录记录。这四步的价值在于把故障域切成了四段第 1 步失败是 DNS 问题第 2 步失败是网络策略问题第 3 步失败是配置问题第 4 步失败才是 frp 本身的握手问题。EOF 只会出现在第 4 步。4. 沿着握手链路逐层定位 EOF到这里进入正题。我处理 EOF 从不猜固定按四层往下走先确认 TCP再确认谁掐断的然后看服务端最后看客户端所在环境。这套顺序的好处是每一步都能把问题范围砍掉一半最坏情况下六分钟能定位。4.1 第一步TCP 到底通没通先用nc -vz -w 3 你的公网IP 7000。如果这一步成功说明包能到、端口有人听EOF 的成因必然在应用层或中间设备。如果这一步失败那你面对的其实不是 EOF 问题而是连通性问题。同时在两端用ss观察连接状态# 客户端侧 ss -tnp | grep 7000 # 服务端侧 ss -tlnp | grep 7000客户端如果看到SYN-SENT长时间不动是包出不去看到ESTABLISHED然后很快消失说明连接建立过又断了和 EOF 的现象吻合。服务端如果LISTEN那行显示的不是 frps 进程那问题就找到了——7000 端口上坐着别的程序。4.2 第二步连接是被谁掐断的这一步是我最依赖的一招两端同时抓包比对断开的时间点和方向。tcpdump -i any -n port 7000 -w /tmp/frp.pcap抓完之后用 Wireshark 打开重点看三件事TCP 三次握手完成没有、Login消息发出后有没有收到任何响应、最后的断开是 FIN 还是 RST。判断逻辑是这样的服务端抓到了 TCP 握手但没抓到Login的数据包 → 数据在客户端出口就没了问题在你这一侧。服务端抓到了Login但 frps 日志里没有任何记录 → frps 进程异常或者被 OOM 杀掉去看journalctl -u frps -n 100和dmesg。客户端收到 RST但服务端从头到尾没记录 → 中间有设备在伪造 RST 包。这种情况在出口策略比较复杂的网络里并不少见典型表现就是怎么改配置都报同一个 EOF。两边都正常收到了对方的包直到某一刻双方同时收到 FIN → 大概率是出口设备回收了空闲会话。抓包这一步看着麻烦实际上比反复改配置试错快得多。改配置是盲猜抓包是取证。4.3 第三步服务端进程与配置是否自洽确认连接被掐断的位置之后再看服务端自身有没有问题。几个高频点服务端的transport.tls.force true而客户端没开 TLS这是秒断 EOF 的头号原因两边对齐即可。服务端和客户端版本差太远也会出问题frpc -v和frps -v对一眼尽量保持同一个大版本跨大版本升级时配置格式可能已经从 INI 变成 TOML直接拿来用会解析失败或静默忽略字段。另外注意服务端日志的log.level别设成error那样握手阶段的记录全被过滤掉了排查时会怀疑人生。4.4 第四步客户端所在环境的四个隐形变量客户端环境里有四个东西平时不显眼出问题时全在暗处使劲系统时间。TLS 握手要校验证书有效期机器时间偏差太大会握手失败。date看一眼跟标准时间差几分钟以内才安心。IPv6 优先。如果serverAddr写的是域名而客户端机器同时有 IPv6解析可能优先拿到 AAAA 记录然后走一条你根本没验证过的 IPv6 出口。表现通常是超时但如果那条路径上有人回 RST就会变成 EOF。解决办法很土但有效/etc/hosts里把域名直接钉到 IPv4 地址。DNS 被改写。有些网络会把 DNS 查询劫持到自己的服务器上返回一个错误页地址。这时候 TCP 居然能连上对面确实在监听frpc 一发Login就被关秒断 EOF。用一个可信的 DNS 单独查一遍对比很快能看出来。多出口与源地址选择。装了 Docker、虚拟机、或者有多个网卡时ip route get 你的公网IP看一下实际走哪块网卡。如果系统选错了源地址包从错误的出口出去可能被直接丢掉也可能被回一个 RST。这个坑我在装了 Docker 的机器上遇到过两次第一次查了整整一晚上。4.5 一张对照表把常见现象和原因对上号观察到的现象最可能的原因处理方向建连后立刻 EOF服务端无日志TLS 单边开启两端tls.force/tls.enable对齐建连后立刻 EOF服务端有握手记录服务端进程崩溃或被系统杀掉查journalctl、dmesg、内存占用一分钟内多次 EOF 且间隔规律出口设备定期回收会话缩短心跳间隔见下一节只在一台机器上出现该机器的时间、DNS 或路由有问题单独排查这一台的环境变量抓包看到客户端收到 RST服务端无感知中间设备伪造 RST更换出口或调整心跳维持会话登录成功但很快断数据量大时更明显MTU 不一致调小 MTU或暂时关掉 tcpMux 验证5. 出口受限网络里的长连接存活策略校园网、宿舍网、办公网这类环境的共同点是出口设备多、策略复杂、会话表项可能很短。frp 的控制连接是一条长期存在的 TCP如果环境不喜欢长连接你就会反复看到建连成功、然后被回收、然后重连、偶尔再来个 EOF 的组合拳。这一节讲怎么让这条连接活得更久。5.1 NAT 会话老化断线最常见的幕后推手家用和宿舍路由器上的 NAT 表项通常在 30 秒到 5 分钟不活动之后就会被清理出口侧设备如果负载高这个时间可能更短。会话一被清掉后续的包到不了目的地表现就是连接凭空消失。frp 本身有心跳机制客户端每隔heartbeatInterval发一次 Ping目的就是让这条会话一直有流量不被判定为空闲。frp 默认心跳间隔是 30 秒勘察超时是 90 秒。如果你所在的环境会话老化时间只有 30 秒那默认值刚好踩在临界点上——每次心跳发出前那一瞬间会话可能已经被清了于是就有了偶发 EOF这种玄学现象。把transport.heartbeatInterval调到 10 到 15 秒很多偶发问题会直接消失。另外提一句内核层的 TCP keepalive。它的默认值是两小时才开始探测对 frp 这种场景基本没用。真想让它起作用得改net.ipv4.tcp_keepalive_time比如设成 60 秒。不过我更推荐用 frp 自己的心跳因为它跑在应用层不依赖系统参数换机器也不用重新配。5.2 心跳、超时、重连参数怎么配把几个关键参数列在一起方便你一次性对齐参数位置默认值建议transport.heartbeatInterval客户端30 秒环境会话短则调至 10~15 秒transport.heartbeatTimeout服务端90 秒保持为心跳间隔的 3 倍以上loginFailExit客户端true网络抖动环境设为 falsetransport.dialServerTimeout客户端10 秒出口慢可适当放大transport.tcpMux两端true排错时可临时关掉做对比有一个反直觉的点值得强调心跳间隔不是越小越好。间隔太小会增加连接上的小包数量某些出口设备对单位时间内连接数或包数异常比较敏感反而更容易被针对。我的经验是把心跳放在 10 到 20 秒之间超过这个范围就要看具体环境的脾气了。还有一个容易忽略的transport.heartbeatTimeout要明显大于客户端的heartbeatInterval否则网络稍微抖一下服务端就会误判客户端掉线然后把连接踢掉。5.3 用 STCP 和 XTCP 减少暴露面默认的 tcp 隧道会在服务端开放一个公网端口别人扫到了就能连。如果你只是想自己访问家里的机器用 STCP 更合适——服务端不开放任何公网端口访问端必须拿着相同的secretKey才能接进来。# 被访问端家里的机器 [[proxies]] name secret-ssh type stcp secretKey 一段足够长的随机串 localIP 127.0.0.1 localPort 22 # 访问端你带着笔记本出门在外 [[visitors]] name secret-ssh-visitor type stcp serverName secret-ssh secretKey 和被访问端一致 bindAddr 127.0.0.1 bindPort 6000配好之后在访问端连127.0.0.1:6000就等于连到了家里那台机器的 22 端口。公网端口扫描器完全看不到这个东西安全性提升很明显。XTCP 走的是点对点打洞流量不经过服务端速度更快但它依赖双方 NAT 的类型成功率不保证只适合当加速手段不适合当唯一方案。5.4 边界要守住只穿透自己有权限的资源这一段必须说清楚。内网穿透工具本身是中性的用来远程访问自己的 NAS、开发机、树莓派是再正常不过的需求。但它不该被用来做任何越界的事不要把它当成访问未授权资源通道不要拿它去碰学校、公司或他人网络里你无权访问的设备和服务也不要用它规避所在网络的任何管理策略。如果所在网络明确不允许这类连接那就遵守规定改用单位提供的正式远程访问方式。这不是客套话是让自己少踩真正的大坑。6. 托管穿透服务还是自建 frps两条路线的账怎么算很多人是从带图形界面的托管穿透服务入门的用一段时间之后开始纠结要不要自己搭。这两条路线的差异在你看不到服务端日志的时候会体现得特别明显。6.1 两条路线的差异对比表维度托管式穿透服务自建 frps上手成本下载客户端、填几个框就能用需要一台公网服务器和基础运维能力公网端口免费线路常随机分配重启可能变自己定固定不变带宽共享通常有限速取决于你买的服务器带宽服务端日志拿不到只能靠客户端日志猜完整可见排查效率质变TLS 配置由服务方定客户端不一定能开两端全由自己控制故障定位EOF 只能换环境试抓包、看日志、逐层定位成本免费额度够轻量使用一台入门云主机 运维精力表格里最关键的一行是服务端日志。EOF 这类握手阶段的故障答案几乎永远在服务端那一侧。托管服务不给你日志你就只能改配置、换客户端、换网络靠排除法慢慢逼近效率差着一个数量级。我自己就是从托管服务转自建的转完之后同一个问题从折腾两天变成了十分钟。6.2 用托管服务时最容易忽略的三个细节如果你还在用托管服务有三个细节值得留意。第一是端口随机分配免费线路通常给你一个随机端口客户端重启后可能变化如果有别的地方引用了这个端口就会莫名其妙失效建议换成付费固定端口或者干脆自建。第二是TLS 策略由服务方决定有些服务端强制要求客户端开启 TLS客户端版本太老不支持的话就会在握手阶段失败报出来的往往正是 EOF 这类含糊错误。第三是流量计费与限速跑大文件传输或者视频流的时候速度会被限制这时候别急着怀疑配置先看看套餐额度。6.3 自建不省心的地方自建也不是全是好处。你需要自己维护一台公网服务器安全组规则、系统更新、日志轮转、frp 版本升级都得管。日志一定要配log.maxDays否则小硬盘的云主机跑两个月就可能被日志撑满而 frps 写不进去日志的时候表现可能是静默失败排查起来更绕。另外服务端暴露在公网上一定要用足够长的 token并且把allowPorts收紧到实际需要的范围这两条是底线。7. 我踩过的那些坑以及顺手总结出来的小技巧前面讲的都是系统性方法这一节聊几个具体的、文档里不太会写的东西。7.1 token 里的特殊字符与引号TOML 格式里#是注释起始符只要你的 token 里带了这个字符后面半截会被直接吞掉两边 token 就看着一样实际不一样。我建议 token 只用大小写字母加数字长度 32 位以上别用符号。还有一个更隐蔽的情况从网页上复制 token 的时候带上了不可见的零宽字符肉眼完全看不出来。遇到过认证死活通不过的时候把两端的 token 用md5sum各算一遍对比一秒钟出结果。7.2 版本代差带来的配置格式陷阱frp 从 0.52 开始把配置文件从 INI 换成了 TOML这个变更坑了不少人。旧配置喂给新版本轻则字段被忽略重则直接报解析错误新配置喂给旧版本直接不认。升级之前一定先看一遍发布说明把配置迁移好再动二进制文件。我的习惯是配置文件统一放/etc/frp/升级前先cp一份带日期的备份出问题五秒回滚。7.3 双栈解析与 hosts 固定这条对 Mac 和树莓派用户特别有用。这些系统在域名同时有 A 和 AAAA 记录时往往优先走 IPv6。如果那条 IPv6 路径不通你看到的现象可能是超时也可能在某些设备上直接变成连接被拒。最省事的办法就是别用域名serverAddr直接写 IPv4 地址如果非要保留域名比如为了以后换 IP 方便就在/etc/hosts里加一行把域名钉到 IPv4简单粗暴但特别有效。7.4 顺手记下的两个小技巧第一个是用 admin 接口看实时状态。frpc 的webServer起来之后可以直接问它当前所有隧道的状态curl -s -u admin:你的密码 http://127.0.0.1:7400/api/status不用翻日志就能看到哪条隧道在线、哪条掉了写个定时脚本轮询这个接口还可以做简单的告警。第二个是排错时把日志降到前台跑。systemd 托管的日志会被切分和轮转排查阶段直接前台跑一次frpc -c /etc/frp/frpc.toml完整日志一口气看完效率比journalctl翻页高不少。定位完再切回 systemd两不耽误。我个人在实际操作里的体会是frp 的报错文案设计得比较薄它只告诉你现象不告诉你原因所以千万别指望靠一条日志找到答案。**把故障域切成解析、连通、配置、握手、会话五段每一段用一个具体命令去验证EOF 这种看起来玄学的问题其实是最容易定位的一类。**真正难缠的从来不是秒断的那种而是那种隔几小时断一次、平时一切正常的偶发情况——它逼着你去理解会话是怎么被回收的也逼着你把参数一项项调对调完之后你对整条链路的理解会比看任何教程都扎实。