github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #2247] frp传输速率减半的问题 #1786

New issue

Closed

opened 2026-05-05 13:09:17 -06:00 by gitea-mirror · 8 comments

gitea-mirror commented

2026-05-05 13:09:17 -06:00

Owner

Originally created by @taipinghehe on GitHub (Feb 17, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2247

情况说明：

我自己在路由器上搭建了frps服务器。
直接通过在路由器开放端口下载NAS文件的实测速度为8MB/s
设备和网络环境不变，通过frp下载NAS文件的实测速度为3MB/s
使用版本0.35
速度相差一半不知道是哪里的问题，请大佬指教。

frpc配置文件

[common]
server_addr = 
server_port = 7000
protocol = tcp
token = 

[http_NAS]
type = http
local_ip = 
local_port = 
pool_count = 5
subdomain = 
use_encryption = true
use_compression = true

[https_NAS]
type = https
local_ip = 
local_port = 
pool_count = 5
subdomain = 
use_encryption = true
use_compression = true

PS：
还有一种比较复杂的网络环境，使用NAS docker方式安装frpc 下载速率400kb/s，相同环境配置不变使用windows主机做frpc下载1MB/s。NAS CPU和内存配置都够。

Originally created by @taipinghehe on GitHub (Feb 17, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2247 #### 情况说明：我自己在路由器上搭建了frps服务器。直接通过在路由器开放端口下载NAS文件的实测速度为8MB/s 设备和网络环境不变，通过frp下载NAS文件的实测速度为3MB/s 使用版本0.35 速度相差一半不知道是哪里的问题，请大佬指教。 #### frpc配置文件 ``` [common] server_addr = server_port = 7000 protocol = tcp token = [http_NAS] type = http local_ip = local_port = pool_count = 5 subdomain = use_encryption = true use_compression = true [https_NAS] type = https local_ip = local_port = pool_count = 5 subdomain = use_encryption = true use_compression = true ``` PS：还有一种比较复杂的网络环境，使用NAS docker方式安装frpc 下载速率400kb/s，相同环境配置不变使用windows主机做frpc下载1MB/s。NAS CPU和内存配置都够。

gitea-mirror

2026-05-05 13:09:17 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:09:21 -06:00

Author

Owner

@taipinghehe commented on GitHub (Feb 19, 2021):

frps服务端配置

[common]
bind_port = 7000
kcp_bind_port = 7000
bind_udp_port = 7001
dashboard_port = 7500
# dashboard 用户名密码，默认都为 admin
dashboard_user = 
dashboard_pwd = 
vhost_http_port = 8800
vhost_https_port = 4433
token = 
subdomain_host = 
max_pool_count = 50
#tcp_mux = true
#log_file = /dev/null
#log_level = info
#log_max_days = 3
# ====================
EOF

@taipinghehe commented on GitHub (Feb 19, 2021): #### frps服务端配置 ``` [common] bind_port = 7000 kcp_bind_port = 7000 bind_udp_port = 7001 dashboard_port = 7500 # dashboard 用户名密码，默认都为 admin dashboard_user = dashboard_pwd = vhost_http_port = 8800 vhost_https_port = 4433 token = subdomain_host = max_pool_count = 50 #tcp_mux = true #log_file = /dev/null #log_level = info #log_max_days = 3 # ==================== EOF ```

gitea-mirror commented

2026-05-05 13:09:22 -06:00

Author

Owner

@taipinghehe commented on GitHub (Feb 26, 2021):

使用浏览器下载文件3MB/s
使用Neat Download Manager多线程下载软件下载文件可以达到7.8MB/s，基本是占满带宽了。
7MB/s时设备状态：
frpc（NAS） CPU 3% RAM 0%
frps（路由器） CPU 88% RAM 空闲90MB

所以frp还是可以占满带宽的，就是单线程带宽不大。
那么问题就是，是什么限制了单线程的带宽，怎么提高单线程的带宽。或者怎么能默认就变成多线，多开frpc指向到一个服务吗？请大佬指教。

@taipinghehe commented on GitHub (Feb 26, 2021): 使用浏览器下载文件3MB/s 使用Neat Download Manager多线程下载软件下载文件可以达到7.8MB/s，基本是占满带宽了。 7MB/s时设备状态： frpc（NAS） CPU 3% RAM 0% frps（路由器） CPU 88% RAM 空闲90MB 所以frp还是可以占满带宽的，就是单线程带宽不大。那么问题就是，是什么限制了单线程的带宽，怎么提高单线程的带宽。或者怎么能默认就变成多线，多开frpc指向到一个服务吗？请大佬指教。

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Mar 1, 2021):

去掉耗 CPU 资源的配置试试

use_encryption = true
use_compression = true

@fatedier commented on GitHub (Mar 1, 2021): 去掉耗 CPU 资源的配置试试 ``` use_encryption = true use_compression = true ```

gitea-mirror commented

2026-05-05 13:09:24 -06:00

Author

Owner

@taipinghehe commented on GitHub (Mar 11, 2021):

去掉耗CPU资源的配置试试
use_encryption = true
use_compression = true

好的
测试后给您回复

@taipinghehe commented on GitHub (Mar 11, 2021): > 去掉耗CPU资源的配置试试 > > ``` > use_encryption = true > use_compression = true > ``` 好的测试后给您回复

gitea-mirror commented

2026-05-05 13:09:24 -06:00

Author

Owner

@rohow commented on GitHub (Mar 25, 2021):

我这边的测试结果是kcp和tcp_mux会因为不同因素对速度造成影响。

环境是本地上载带宽50M、服务器日本G口软银线路。

当开启kcp 延迟会大幅下降，适合代理html 或者高并发需要快速响应的接口。但此时峰值速度会受到运营商或者frps所在服务器的QOS影响(udp)，只有1MB/s - 2MB/s。

当关闭kcp使用tcp时也是上面的速度，此时有可能是tcp stream复用造成的。

当两个选项都关闭时可以差不多单线程跑满本地带宽 5MB/s - 6MB/s

问题是kcp和关闭tcp_mux不能同时设置，会造成所有代理都无法访问，当前解决方案是同时开启两个服务，依据文件类型、接口类型分发到两个frps实例上。

如果 type 字段可以支持单独设置kcp类型，这样就可以很灵活配置了

@rohow commented on GitHub (Mar 25, 2021): 我这边的测试结果是kcp和tcp_mux会因为不同因素对速度造成影响。环境是本地上载带宽50M、服务器日本G口软银线路。当开启kcp 延迟会大幅下降，适合代理html 或者高并发需要快速响应的接口。但此时峰值速度会受到运营商或者frps所在服务器的QOS影响(udp)，只有1MB/s - 2MB/s。当关闭kcp使用tcp时也是上面的速度，此时有可能是tcp stream复用造成的。当两个选项都关闭时可以差不多单线程跑满本地带宽 5MB/s - 6MB/s 问题是kcp和关闭tcp_mux不能同时设置，会造成所有代理都无法访问，当前解决方案是同时开启两个服务，依据文件类型、接口类型分发到两个frps实例上。如果 type 字段可以支持单独设置kcp类型，这样就可以很灵活配置了

gitea-mirror commented

2026-05-05 13:09:24 -06:00

Author

Owner

@fatedier commented on GitHub (Mar 25, 2021):

@rohow tcp_mux 理论上不会有那么大的影响，可以在同一台机器上测试一下？

@fatedier commented on GitHub (Mar 25, 2021): @rohow tcp_mux 理论上不会有那么大的影响，可以在同一台机器上测试一下？

gitea-mirror commented

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

Author

Owner

@github-actions[bot] commented on GitHub (May 10, 2021):

Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (May 10, 2021): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.

gitea-mirror commented

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

Author

Owner

@taipinghehe commented on GitHub (Jun 11, 2021):

我找到了网络管理员看到了上网行为管理的后台我们这个网络对单个IP限制下载5mb上传2mb，所以我想，估计是上网行为管理限制了网速使得frp的速度起不来

@taipinghehe commented on GitHub (Jun 11, 2021): 我找到了网络管理员看到了上网行为管理的后台我们这个网络对单个IP限制下载5mb上传2mb，所以我想，估计是上网行为管理限制了网速使得frp的速度起不来