mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #478] frp所有版本都存在的一个严重问题 #361
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#361
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hijk1234 on GitHub (Oct 5, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/478
用frp来充当转发的角色，作者可以去百度，搜索gh0st随便下载个软件用来测试TCP长时间连接(七八个小时)。一个晚上就能测试出来所有问题，比如当一个tcp连接由于某种未知原因死了后(其实并不是真死，tcpview查看用户端网络连接状态其实还是ESTABLISHED)，frp没有能力及时的检测出来。通俗的来讲就是frp无法及时感知用户端和客户端之间（注意，用户端【gh0st软件服务端】和客户端【gh0st软件生成的客户端】）tcp连接的健康状态。这样就会导致假死连接。出现假死的时候只能在gh0st服务端手动去点一下，这个tcp连接才会释放。然后经过一段时间后（这个连上来的时间不知是多久，不会掉线后，立刻重新连接上来）才会重新连接上来。当同时有上百个gh0st客户端连接gh0st服务端，这个问题会导致gh0st服务端连接上来的客户端特别乱，基本没办法使用了。
@sunnyboy00 commented on GitHub (Oct 5, 2017):
我觉得在这个问题应该是后台服务来管理，frp 只做中继
@hijk1234 commented on GitHub (Oct 5, 2017):
你错了，经过测试。使用圣剑内网通的话，就不会存在这个问题。同样的客户端，服务端，用户端。用圣剑做反向代理TCP就没问题。，换了frp就出现很大的问题。说明frp的TCP模块还是有很大的问题的。这还是四五个电脑测试一个晚上的结果。如果是上百个电脑，那就大乱特乱了。
@yanggis commented on GitHub (Oct 6, 2017):
这个问题我很早就报告过了，可惜作者一直没有重视:
https://github.com/fatedier/frp/issues/457
@yanggis commented on GitHub (Oct 6, 2017):
现在的解决办法就是隔一段时间把frp客户端重启一次。
@yanggis commented on GitHub (Oct 6, 2017):
@hijk1234 不过你也不用借机用商业软件来黑frp，虽然它有问题，我还是希望推荐更多的人用frp，把那些收费的内网通软件全部灭掉，包括你提到的什么软件。
@hijk1234 commented on GitHub (Oct 6, 2017):
@yanggis frp从第1版到现在最新版本，TCP模块都存在这个问题。只是向作者真实反馈问题，没有黑frp之说。
@xirotech commented on GitHub (Oct 9, 2017):
单纯就问题来说 这是一个影响业务持续性的严重问题
不过我好想看到一个拥有上百只肉鸡的黑产老铁现身了。 呵呵呵
@dsf848dfgvs commented on GitHub (Oct 11, 2017):
@fatedier frp确实有这个问题，老早以前就知道了。这个问题估计比较难，不然作者不会到现在也不修复哦。
@zhangcunxiang commented on GitHub (Oct 19, 2017):
@dsf848dfgvs 确实是这样，我自己用erlang 撸的 一个 tcp 转发服务也存在这样的问题，莫名其妙连接就假死了，但是双方都认为对方是正常连接着的，之前试过 ngrok 1.7 也存在这个问题，不知道有没有大牛能够指点指点 解决方案
@fatedier commented on GitHub (Oct 19, 2017):
@zhangcunxiang 双方都认为对方是正常的，你们的应用都不加心跳包的？
@hijk1234 commented on GitHub (Oct 19, 2017):
@fatedier 把frp换成圣剑内网通，其它都不变，就一切正常了。那还不能说明frp tcp方面存在问题吗？
@fatedier commented on GitHub (Oct 19, 2017):
@hijk1234 你的逻辑有问题，XXXX 和 frp 没有关系，其他项目有的功能 frp 不一定会支持，取决于项目的发展和目的。
客户端和服务端的通信，需要考虑网络环境的各种异常，所以通常我们会在通信协议中加上心跳包，比如 frpc 和 frps 两者的交互，即使没有数据传输，也会定期发送心跳确认服务正常。所以即使你把 frpc 客户端机器上的网线拔了，frps 端也是可以感知到客户端异常。
同理，用户自己的程序也可以自己通过心跳维持服务正常，和中间的代理层没有关系。
@hijk1234 commented on GitHub (Oct 19, 2017):
@fatedier 不太明白你说的，感觉frp TCP设计的确实有缺陷，说不上来什么问题。还是觉得既然frp 支持tcp模块，还是做的完善一些比较好。
@fatedier commented on GitHub (Oct 19, 2017):
@hijk1234 如果还不明白可以先去阅读一些相关的文章，TCP 协议，网络编程相关的，常见的服务器程序对于各种网络异常问题的处理，然后熟悉了之后再一起讨论讨论，看是哪方面的问题。
从我的角度来看，这个问题是在帮写的不完善的用户程序解决问题，暂时还没有这个计划。
@hulucc commented on GitHub (Oct 12, 2020):
frp用在生产环境也遇到了类似的问题，工作一段时间以后就出现假死，必须重启，每月都会来几次。
@Yangxcasear commented on GitHub (Sep 20, 2023):
I also having this issue, and fix it.
I guess this problem may occurs by CMD's default properties.
When u open a .bat to run frp, the apperd cmd window default open "Qucik Edit" function,
and the meaning of "Quick Edit" function is that when your mouse click cmd window , the tasks that running with cmd
windows will be paused, so i suggest to right click running frp's CMD window's top bar , and unchecked "Qucik Edit"
function in it's properties.
Hope it can help you. @fatedier
@HellowBoy commented on GitHub (Feb 7, 2025):
我是这样解决的，目前测试没问题了。
1、客户端和服务器端关闭端口复用，下面只给出了服务端的配置，客户端也有相应的设置
transport.tcpMux = false
transport.tcpMuxKeepaliveInterval = 60
transport.heartbeatTimeout = 60
2、部分客户端插件注册间隔时间设置为0。如openwrt中
大家可以试试，有用点赞呢