[GH-ISSUE #1499] 未知条件触发的FRPS网络吞吐下降

gitea-mirror commented

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

Owner

Originally created by @Milokita on GitHub (Nov 6, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1499

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 将会直接关闭。)
(请不要在 issue 评论中出现无意义的加1，我也是 等内容，将会被直接删除。)
(由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。)

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.29

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

Configures you used:
`
[common]
server_addr = REMOVED
server_port = 1234
token = REMOVED
protocol = kcp

[https]
type = https
local_ip = 127.0.0.1
local_port = 443
use_encryption = false
use_compression = false
proxy_protocol_version = v2
custom_domains = REMOVED
subdomain = www

[http]
type = http
local_ip = 127.0.0.1
local_port = 80
use_encryption = false
use_compression = false
proxy_protocol_version = v2
custom_domains = REMOVED
subdomain = www
`

Steps to reproduce the issue:

使用nextcloud并行http2上传和下载

Describe the results you received:
稳定传输

Describe the results you expected:
在传输过程中吞吐突然降低并维持在100KB（正常稳定在最大带宽），
传输过程中突然中断链接有机会触发这个情况

Additional information you deem important (e.g. issue happens only occasionally):
近期出现了这个情况，远端服务器是阿里云香港。
在发生这个情况时，frp转发的HTTPS吞吐会降到100KB/s左右，换用不同的客户端都是这样。使用SCP测试任然可以达到最大带宽。重启frpc/frps后吞吐恢复。

** 日志中并没有出现错误**

netstat检查没有发现产生巨量的端口监听，top上frp进程数量cpu占用正常

Can you point out what caused this issue (optional)

@shadoweb 你有没有遇到过这个情况

Originally created by @Milokita on GitHub (Nov 6, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1499 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 将会直接关闭。) (请不要在 issue 评论中出现无意义的 **加1**，**我也是** 等内容，将会被直接删除。) (由于个人精力有限，和系统环境，网络环境等相关的求助问题请转至其他论坛或社交平台。) 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.29 **What operating system and processor architecture are you using (`go env`)?** Debian 9.9 **Configures you used:** ` [common] server_addr = REMOVED server_port = 1234 token = REMOVED protocol = kcp [https] type = https local_ip = 127.0.0.1 local_port = 443 use_encryption = false use_compression = false proxy_protocol_version = v2 custom_domains = REMOVED subdomain = www [http] type = http local_ip = 127.0.0.1 local_port = 80 use_encryption = false use_compression = false proxy_protocol_version = v2 custom_domains = REMOVED subdomain = www ` **Steps to reproduce the issue:** 1. 使用nextcloud并行http2上传和下载 **Describe the results you received:** 稳定传输 **Describe the results you expected:** 在传输过程中吞吐突然降低并维持在100KB（正常稳定在最大带宽），传输过程中突然中断链接有机会触发这个情况 **Additional information you deem important (e.g. issue happens only occasionally):** 近期出现了这个情况，远端服务器是阿里云香港。在发生这个情况时，frp转发的HTTPS吞吐会降到100KB/s左右，换用不同的客户端都是这样。使用SCP测试任然可以达到最大带宽。重启frpc/frps后吞吐恢复。 ** 日志中并没有出现错误** netstat检查没有发现产生巨量的端口监听，top上frp进程数量cpu占用正常 **Can you point out what caused this issue (optional)** @shadoweb 你有没有遇到过这个情况

gitea-mirror

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

closed this issue
added the
question
label

gitea-mirror commented

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

Author

Owner

@shadoweb commented on GitHub (Nov 6, 2019):

如果是web方式,可以尝试nextcloud的Flowupload应用
客户端的话,我只用过foldersync和nextcloud的安卓端
你提到
frp转发的HTTPS吞吐会降到100KB/s左右
换用不同的客户端都是这样。使用SCP测试任然可以达到最大带宽。重启frpc/frps后吞吐恢复。

这个建议你长期观察一下.
另外,注意阿里云香港,阿里云针对https有没有针对性的检测或者我们的长城有没有检测,这个不太清楚.

看你的测试方式,你比我专业.

另外,我现在使用有时候,会直接通过服务器直接上传文件,然后配置一下occ每小时扫描一次.体验还可以.

因为网络涉及的因素太多,每个人的情况不一样.

建议找到适合自己的方式使用即可.

如果是自用的话.

@shadoweb commented on GitHub (Nov 6, 2019): 如果是web方式,可以尝试nextcloud的Flowupload应用客户端的话,我只用过foldersync和nextcloud的安卓端你提到 frp转发的HTTPS吞吐会降到100KB/s左右换用不同的客户端都是这样。使用SCP测试任然可以达到最大带宽。重启frpc/frps后吞吐恢复。这个建议你长期观察一下. 另外,注意阿里云香港,阿里云针对https有没有针对性的检测或者我们的长城有没有检测,这个不太清楚. 看你的测试方式,你比我专业. 另外,我现在使用有时候,会直接通过服务器直接上传文件,然后配置一下occ每小时扫描一次.体验还可以. 因为网络涉及的因素太多,每个人的情况不一样. 建议找到适合自己的方式使用即可. 如果是自用的话.

gitea-mirror commented

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

Author

Owner

@Milokita commented on GitHub (Nov 6, 2019):

后来在日志当中发现了这么一条错误：
2019/11/07 06:57:44 [W] [http.go:95] do http proxy request error: http: no Host in request URL

@Milokita commented on GitHub (Nov 6, 2019): 后来在日志当中发现了这么一条错误： ` 2019/11/07 06:57:44 [W] [http.go:95] do http proxy request error: http: no Host in request URL `

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Nov 7, 2019):

@Milokita 这个错误是 http 类型才会有的，和 https 无关。

@fatedier commented on GitHub (Nov 7, 2019): @Milokita 这个错误是 http 类型才会有的，和 https 无关。

gitea-mirror commented

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

Author

Owner

@Milokita commented on GitHub (Nov 7, 2019):

@Milokita 这个错误是 http 类型才会有的，和 https 无关。

后来发现如果使用frp转发ssh，会出现从键盘输入到屏幕有显示延迟升高到1秒左右（估计值）。
这个时候基于ssh tunneling的ssh （不同端口）延迟正常 @fatedier

@Milokita commented on GitHub (Nov 7, 2019): > > > @Milokita 这个错误是 http 类型才会有的，和 https 无关。后来发现如果使用frp转发ssh，会出现从键盘输入到屏幕有显示延迟升高到1秒左右（估计值）。这个时候基于ssh tunneling的ssh （不同端口）延迟正常 @fatedier

gitea-mirror commented

2026-05-05 12:45:40 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 7, 2019):

这个是和网络环境非常相关的问题，最简单的验证方法，你把 frps 和 frpc 都搭在本地，屏蔽掉外部网络这一层，然后再 ssh 登录尝试，看是否会有延迟，相当于是排除法。

网络环境的话，比如对某种检测到的协议限流甚至中断，这个只能自己尝试，比如对传输的协议进行加密或者更改传输协议。

@fatedier commented on GitHub (Nov 7, 2019): 这个是和网络环境非常相关的问题，最简单的验证方法，你把 frps 和 frpc 都搭在本地，屏蔽掉外部网络这一层，然后再 ssh 登录尝试，看是否会有延迟，相当于是排除法。网络环境的话，比如对某种检测到的协议限流甚至中断，这个只能自己尝试，比如对传输的协议进行加密或者更改传输协议。

gitea-mirror commented

2026-05-05 12:45:40 -06:00

Author

Owner

@Milokita commented on GitHub (Nov 11, 2019):

这个是和网络环境非常相关的问题，最简单的验证方法，你把 frps 和 frpc 都搭在本地，屏蔽掉外部网络这一层，然后再 ssh 登录尝试，看是否会有延迟，相当于是排除法。

网络环境的话，比如对某种检测到的协议限流甚至中断，这个只能自己尝试，比如对传输的协议进行加密或者更改传输协议。

目前进行了一轮测试之后，结果如下

程序模式传输速度
FRP TCP模式转发SCP 3MB/s (MAX)
SSH TUNNELING 3MB/s
FRPC SCP配置：
type = tcp local_ip = 127.0.0.1 local_port = 22 use_encryption = false use_compression = false remote_port = 2222
FRP HTTPS转发: 未开启压缩、加密：100KB/s 都开启： 100KB/s （均为故障时的数据，正常为MAX，排除了各机器的CPU、内存、硬盘问题）故障时SSH TUNNELING正常，FRP转发的HTTPS、SSH都出现问题。
配置：
type = https local_ip = 127.0.0.1 local_port = 443 use_encryption = false use_compression = false proxy_protocol_version = v2 custom_domains = REMOVED subdomain = www
另外FPRC上还有一个用于HTTP重定向的服务和空置的UDP转发。

如果不重启FRP则故障恒定

@Milokita commented on GitHub (Nov 11, 2019): > > > 这个是和网络环境非常相关的问题，最简单的验证方法，你把 frps 和 frpc 都搭在本地，屏蔽掉外部网络这一层，然后再 ssh 登录尝试，看是否会有延迟，相当于是排除法。 > > 网络环境的话，比如对某种检测到的协议限流甚至中断，这个只能自己尝试，比如对传输的协议进行加密或者更改传输协议。目前进行了一轮测试之后，结果如下程序模式传输速度 FRP TCP模式转发SCP 3MB/s (MAX) SSH TUNNELING 3MB/s FRPC SCP配置： ` type = tcp local_ip = 127.0.0.1 local_port = 22 use_encryption = false use_compression = false remote_port = 2222 ` FRP HTTPS转发: 未开启压缩、加密：100KB/s 都开启： 100KB/s （均为故障时的数据，正常为MAX，排除了各机器的CPU、内存、硬盘问题）故障时SSH TUNNELING正常，FRP转发的HTTPS、SSH都出现问题。配置： ` type = https local_ip = 127.0.0.1 local_port = 443 use_encryption = false use_compression = false proxy_protocol_version = v2 custom_domains = REMOVED subdomain = www ` 另外FPRC上还有一个用于HTTP重定向的服务和空置的UDP转发。如果不重启FRP则故障恒定

gitea-mirror commented

2026-05-05 12:45:41 -06:00

Author

Owner

@jrdeng commented on GitHub (Apr 7, 2020):

我这边遇到类似的情况，不知道能否一起分析：
scp nas --> vps 4MB/s
scp vps --> clientPC 2MB/s

如果vps架了 frps：
scp nas --(vps)--> clientPC 只有 400KB/s ~ 500KB/s

vps用的 linode fremont，开了bbr。
frps 用的 tcp + tsl_only，没用udp、compress等。

麻烦指导一下分析方向。。。
谢谢

@jrdeng commented on GitHub (Apr 7, 2020): 我这边遇到类似的情况，不知道能否一起分析： scp nas --> vps 4MB/s scp vps --> clientPC 2MB/s 如果vps架了 frps： scp nas --(vps)--> clientPC 只有 400KB/s ~ 500KB/s vps用的 linode fremont，开了bbr。 frps 用的 tcp + tsl_only，没用udp、compress等。麻烦指导一下分析方向。。。谢谢

gitea-mirror commented

2026-05-05 12:45:41 -06:00

Author

Owner

@jrdeng commented on GitHub (Apr 8, 2020):

用 ssh -R ，发现速度快不少，难道是因为 frp的包被墙干扰了？

@jrdeng commented on GitHub (Apr 8, 2020): 用 ssh -R ，发现速度快不少，难道是因为 frp的包被墙干扰了？

gitea-mirror commented

2026-05-05 12:45:41 -06:00

Author

Owner

@Milokita commented on GitHub (Apr 10, 2020):

我后来是开了BBR速度就很稳定了

用 ssh -R ，发现速度快不少，难道是因为 frp的包被墙干扰了？

@Milokita commented on GitHub (Apr 10, 2020): 我后来是开了BBR速度就很稳定了 > > > 用 ssh -R ，发现速度快不少，难道是因为 frp的包被墙干扰了？

Rows
Columns

[GH-ISSUE #1499] 未知条件触发的FRPS网络吞吐下降 #1180