[GH-ISSUE #457] 访问量比较大的时候丢包比较严重

gitea-mirror commented

2026-05-05 12:09:15 -06:00

Owner

Originally created by @yanggis on GitHub (Sep 9, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/457

Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。)

Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST

What version of frp are you using (./frpc -v or ./frps -v)?
0.12

What operating system and processor architecture are you using (go env)?

Linux
Configures you used:
默认配置

Steps to reproduce the issue:

配置squid服务器
设置并发访问500个以上，同时访问数据交换，超过4个小时，就开始出现数据访问不成功，代理数据加载不了。
重启frpc客户端以后问题解决，现在只能靠每隔一小时重启一次暂时处理。

Describe the results you received:
并发数量大的时候会出现数据访问不成功。

Describe the results you expected:
无

Additional information you deem important (e.g. issue happens only occasionally):

无
Can you point out what caused this issue (optional)
无

Originally created by @yanggis on GitHub (Sep 9, 2017). Original GitHub issue: https://github.com/fatedier/frp/issues/457 Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly. (为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。) Use the commands below to provide key information from your environment: You do NOT have to include this information if this is a FEATURE REQUEST **What version of frp are you using (./frpc -v or ./frps -v)?** 0.12 **What operating system and processor architecture are you using (`go env`)?** Linux **Configures you used:** 默认配置 **Steps to reproduce the issue:** 1. 配置squid服务器 2. 设置并发访问500个以上，同时访问数据交换，超过4个小时，就开始出现数据访问不成功，代理数据加载不了。 3. 重启frpc客户端以后问题解决，现在只能靠每隔一小时重启一次暂时处理。 **Describe the results you received:** 并发数量大的时候会出现数据访问不成功。 **Describe the results you expected:** 无 **Additional information you deem important (e.g. issue happens only occasionally):** 无 **Can you point out what caused this issue (optional)** 无

gitea-mirror

2026-05-05 12:09:15 -06:00

closed this issue
added the
WaitingForInfo
label

gitea-mirror commented

2026-05-05 12:09:20 -06:00

Author

Owner

@fatedier commented on GitHub (Sep 13, 2017):

重现步骤可以再详细一些，确保我能在本地环境复现这个问题。

@fatedier commented on GitHub (Sep 13, 2017): 重现步骤可以再详细一些，确保我能在本地环境复现这个问题。

gitea-mirror commented

2026-05-05 12:09:23 -06:00

Author

Owner

@yanggis commented on GitHub (Sep 13, 2017):

您好，感谢回复。
1.配置squid服务器作为frpc的入口，数据进入squid作为代理；
2.在另外一台机器上访问，同时并发访问500个以上访问squid代理服务器，如果持续不断的请求数据超过4个小时，就开始出现数据访问不成功，代理数据加载不了。
3.重启frpc客户端以后问题解决，现在只能靠每隔一小时重启一次暂时处理。

@yanggis commented on GitHub (Sep 13, 2017): 您好，感谢回复。 1.配置squid服务器作为frpc的入口，数据进入squid作为代理； 2.在另外一台机器上访问，同时并发访问500个以上访问squid代理服务器，如果持续不断的请求数据超过4个小时，就开始出现数据访问不成功，代理数据加载不了。 3.重启frpc客户端以后问题解决，现在只能靠每隔一小时重启一次暂时处理。

gitea-mirror commented

2026-05-05 12:09:25 -06:00

Author

Owner

@zhongru2001 commented on GitHub (Mar 21, 2018):

对，并发量大时，超几个小时会获取不了数据。要重起才行。我用的是也是最新版本，高并发稳定性方面要改进一下

@zhongru2001 commented on GitHub (Mar 21, 2018): 对，并发量大时，超几个小时会获取不了数据。要重起才行。我用的是也是最新版本，高并发稳定性方面要改进一下

gitea-mirror commented

2026-05-05 12:09:26 -06:00

Author

Owner

@kavid commented on GitHub (Apr 2, 2018):

我是windows系统，也会出现这个问题，直接出现frps的页面not 404

@kavid commented on GitHub (Apr 2, 2018): 我是windows系统，也会出现这个问题，直接出现frps的页面not 404

gitea-mirror commented

2026-05-05 12:09:27 -06:00

Author

Owner

@immortalt commented on GitHub (Apr 30, 2018):

我也遇到了这个问题。
系统是Ubuntu 16.04.4。
本来一切正常，没感觉什么问题。
直到我把大量访问量交给frps去处理，
然后就可能出现frps还在运行，却无法访问任何页面的情况。
重启frps解决问题。frpc我是设置了脚本，断线退出自动重连的。
现在我也感觉仿佛得加入定时重启frps。
但是那样一来TCP的连接比如ssh可能就中断了，会产生不利的影响。

@immortalt commented on GitHub (Apr 30, 2018): 我也遇到了这个问题。系统是Ubuntu 16.04.4。本来一切正常，没感觉什么问题。直到我把大量访问量交给frps去处理，然后就可能出现frps还在运行，却无法访问任何页面的情况。重启frps解决问题。frpc我是设置了脚本，断线退出自动重连的。现在我也感觉仿佛得加入定时重启frps。但是那样一来TCP的连接比如ssh可能就中断了，会产生不利的影响。

gitea-mirror commented

2026-05-05 12:09:28 -06:00

Author

Owner

@missdeer commented on GitHub (May 1, 2018):

我也遇到了不工作的情况，frps在Debian Linux x64上，frpc在macOS 10.13上，开了个http反代，报错是socket: too many open files，我觉得这个可能是root cause，是不是frpc存在句柄泄漏。同时开的socks5反代和dns反代都只是返回空，没有更多错误信息。

pi@shhtpc:~$ curl --proxy 127.0.0.1:6001 myip.ipip.net -v
* Rebuilt URL to: myip.ipip.net/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to (nil) (127.0.0.1) port 6001 (#0)
> GET http://myip.ipip.net/ HTTP/1.1
> Host: myip.ipip.net
> User-Agent: curl/7.52.1
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 500 Internal Server Error
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Tue, 01 May 2018 11:58:47 GMT
< Content-Length: 109
<
dial tcp: lookup myip.ipip.net on 64.104.123.245:53: dial udp 64.104.123.245:53: socket: too many open files
* Curl_http_done: called premature == 0
* Connection #0 to host (nil) left intact

@missdeer commented on GitHub (May 1, 2018): 我也遇到了不工作的情况，frps在Debian Linux x64上，frpc在macOS 10.13上，开了个http反代，报错是`socket: too many open files`，我觉得这个可能是root cause，是不是frpc存在句柄泄漏。同时开的socks5反代和dns反代都只是返回空，没有更多错误信息。 ``` pi@shhtpc:~$ curl --proxy 127.0.0.1:6001 myip.ipip.net -v * Rebuilt URL to: myip.ipip.net/ * Trying 127.0.0.1... * TCP_NODELAY set * Connected to (nil) (127.0.0.1) port 6001 (#0) > GET http://myip.ipip.net/ HTTP/1.1 > Host: myip.ipip.net > User-Agent: curl/7.52.1 > Accept: */* > Proxy-Connection: Keep-Alive > < HTTP/1.1 500 Internal Server Error < Content-Type: text/plain; charset=utf-8 < X-Content-Type-Options: nosniff < Date: Tue, 01 May 2018 11:58:47 GMT < Content-Length: 109 < dial tcp: lookup myip.ipip.net on 64.104.123.245:53: dial udp 64.104.123.245:53: socket: too many open files * Curl_http_done: called premature == 0 * Connection #0 to host (nil) left intact ```

gitea-mirror commented

2026-05-05 12:09:28 -06:00

Author

Owner

@yanggis commented on GitHub (May 1, 2018):

FRP如果是个人玩玩可以，大数据访问极其不稳定，生产环境想做内网穿透我建议用zerotier，免费的UDP穿透，https://www.zerotier.com/。

@yanggis commented on GitHub (May 1, 2018): FRP如果是个人玩玩可以，大数据访问极其不稳定，生产环境想做内网穿透我建议用zerotier，免费的UDP穿透，https://www.zerotier.com/。

gitea-mirror commented

2026-05-05 12:09:30 -06:00

Author

Owner

@kavid commented on GitHub (May 2, 2018):

300ms，怎么生产环境

@kavid commented on GitHub (May 2, 2018): 300ms，怎么生产环境

gitea-mirror commented

2026-05-05 12:09:32 -06:00

Author

Owner

@fatedier commented on GitHub (May 2, 2018):

v0.18.0 版本对多路复用做了修改，应该是产生这个问题的原因，先 close 这个 issue，如果新版本仍然有问题，再 reopen。

@fatedier commented on GitHub (May 2, 2018): v0.18.0 版本对多路复用做了修改，应该是产生这个问题的原因，先 close 这个 issue，如果新版本仍然有问题，再 reopen。

gitea-mirror commented

2026-05-05 12:09:34 -06:00

Author

Owner

@immortalt commented on GitHub (May 2, 2018):

@yanggis 官方网站都打不开。。。

@immortalt commented on GitHub (May 2, 2018): @yanggis 官方网站都打不开。。。

gitea-mirror commented

2026-05-05 12:09:35 -06:00

Author

Owner

@yanggis commented on GitHub (May 3, 2018):

@Immortalt 你需要翻墙访问吧？

@yanggis commented on GitHub (May 3, 2018): @Immortalt 你需要翻墙访问吧？

gitea-mirror commented

2026-05-05 12:09:36 -06:00

Author

Owner

@immortalt commented on GitHub (May 4, 2018):

@fatedier 0.18.0还是存在这个问题。我服务器每天访问量大了frps就无法访问，得重启frps才能恢复正常。报错：
2018/05/03 22:36:43 http: Accept error: accept tcp [::]:80: accept4: too many open files; retrying in 1s
我现在都是明天手动重启一次。
我在想要不先写个半天重启一次的脚本应付一下。
希望以后的新版本能稳定好用，解决这个问题。

@immortalt commented on GitHub (May 4, 2018): @fatedier 0.18.0还是存在这个问题。我服务器每天访问量大了frps就无法访问，得重启frps才能恢复正常。报错： 2018/05/03 22:36:43 http: Accept error: accept tcp [::]:80: accept4: too many open files; retrying in 1s 我现在都是明天手动重启一次。我在想要不先写个半天重启一次的脚本应付一下。希望以后的新版本能稳定好用，解决这个问题。

gitea-mirror commented

2026-05-05 12:09:37 -06:00

Author

Owner

@missdeer commented on GitHub (May 4, 2018):

@Immortalt 你这个跟我应该是同一个原因，估计frpc 有句柄泄漏

@missdeer commented on GitHub (May 4, 2018): @Immortalt 你这个跟我应该是同一个原因，估计frpc 有句柄泄漏

gitea-mirror commented

2026-05-05 12:09:38 -06:00

Author

Owner

@fatedier commented on GitHub (May 4, 2018):

@Immortalt 你的问题可以重新提交一个 issue，具体说明下配置以及测试的请求以及详细的日志调试信息。如果能够有易于搭建，可以稳定复现的环境，会更容易解决。

@fatedier commented on GitHub (May 4, 2018): @Immortalt 你的问题可以重新提交一个 issue，具体说明下配置以及测试的请求以及详细的日志调试信息。如果能够有易于搭建，可以稳定复现的环境，会更容易解决。

gitea-mirror commented

2026-05-05 12:09:39 -06:00

Author

Owner

@kratos9394 commented on GitHub (Jun 12, 2020):

之前本地erp带数据库的，只是做上传数据还可以，换了个远程操作数据库的，每天都死，负载均衡也会死两边都要重启，流量也不是很大，一天首发个一两个猪

@kratos9394 commented on GitHub (Jun 12, 2020): 之前本地erp带数据库的，只是做上传数据还可以，换了个远程操作数据库的，每天都死，负载均衡也会死两边都要重启，流量也不是很大，一天首发个一两个猪

gitea-mirror referenced this issue

2026-05-05 14:37:12 -06:00

[PR #347] [CLOSED] Merge pull request #1 from fatedier/master #4182

Rows
Columns

[GH-ISSUE #457] 访问量比较大的时候丢包比较严重 #347