[GH-ISSUE #662] Frpc的Windows客户端穿透的转发速率只有路由器或者Linux的Frpc客户端的1/3

gitea-mirror commented

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

Owner

Originally created by @huxuansong on GitHub (Mar 13, 2018).
Original GitHub issue: https://github.com/fatedier/frp/issues/662

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)?
1.6.0

What operating system and processor architecture are you using (go env)?
Windows 7 / intel G3250

Configures you used:

frps.ini
[common]
bind_port =
bind_udp_port =
kcp_bind_port =
privilege_token = *******

frpc.ini
[common]
server_addr = ...*
server_port = ***
protocol = tcp
tcp_mux = false
protocol = kcp
privilege_token = **********
[grdp]
type = tcp
local_ip = 127.0.0.1
local_port = 3389
remote_port = 13389

Steps to reproduce the issue:
1.经过frpc的Windows版本客户端穿透访问远程桌面
2.经过frpc的路由器或者局域网linux客户端穿透访问远程桌面
3.同样的Frps服务器
4.同一台电脑，并且访问的是同一台Windows的远程桌面
5.在远程桌面观看视频或则图片等消耗大量带宽的动作
6.监测网卡的上传速率

Describe the results you received:
Describe the results you expected:

Frpc的Windows客户端穿透的转发速率只有路由器或者Linux的Frpc客户端的1/3
Frpc的Windows客户端，网卡上传速率只有5-6mbps
而经过路由器或则局域网的frpc访问远程桌面，网卡的上传速率有20-30mbps

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

Can you point out what caused this issue (optional)

Originally created by @huxuansong on GitHub (Mar 13, 2018). Original GitHub issue: https://github.com/fatedier/frp/issues/662 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)?** 1.6.0 **What operating system and processor architecture are you using (`go env`)?** Windows 7 / intel G3250 **Configures you used:** frps.ini [common] bind_port = **** bind_udp_port = **** kcp_bind_port = **** privilege_token = *********** --------------------------- frpc.ini [common] server_addr = ...* server_port = *** protocol = tcp tcp_mux = false protocol = kcp privilege_token = ********** [grdp] type = tcp local_ip = 127.0.0.1 local_port = 3389 remote_port = 13389 **Steps to reproduce the issue:** 1.经过frpc的Windows版本客户端穿透访问远程桌面 2.经过frpc的路由器或者局域网linux客户端穿透访问远程桌面 3.同样的Frps服务器 4.同一台电脑，并且访问的是同一台Windows的远程桌面 5.在远程桌面观看视频或则图片等消耗大量带宽的动作 6.监测网卡的上传速率 **Describe the results you received:** **Describe the results you expected:** Frpc的Windows客户端穿透的转发速率只有路由器或者Linux的Frpc客户端的1/3 Frpc的Windows客户端，网卡上传速率只有5-6mbps 而经过路由器或则局域网的frpc访问远程桌面，网卡的上传速率有20-30mbps **Additional information you deem important (e.g. issue happens only occasionally):** **Can you point out what caused this issue (optional)**

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@wwqgtxx commented on GitHub (Mar 20, 2018):

感觉和windows的tcp拥塞控制有关，这个问题在我这里也很明显

@wwqgtxx commented on GitHub (Mar 20, 2018): 感觉和windows的tcp拥塞控制有关，这个问题在我这里也很明显

gitea-mirror commented

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

Author

Owner

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

确实如此，这不是frp独有的问题。
一端是Windows，一端是Linux，广域网大流量的情况下，用网络检测程序iperf就很容易测出来速度并不高，远远跑不到标称的带宽（高速局域网除外），要在Windows侧把socket的TCP window size设大，比如256K，速度就上去了。
如果两端都是Linux系统，就不需要改这个参数，改了反而速度降了，用系统默认的刚好。
示例C代码：

const int nNrKb = 256;
int nBuffSize = 1024 * nNrKb;
int nRet = setsockopt(nSocket, SOL_SOCKET, SO_SNDBUF, (char *)&nBuffSize, sizeof(int));
nRet = setsockopt(nSocket, SOL_SOCKET, SO_RCVBUF, (char *)&nBuffSize, sizeof(int));

@missdeer commented on GitHub (May 1, 2018): 确实如此，这不是frp独有的问题。一端是Windows，一端是Linux，广域网大流量的情况下，用网络检测程序iperf就很容易测出来速度并不高，远远跑不到标称的带宽（高速局域网除外），要在Windows侧把socket的TCP window size设大，比如256K，速度就上去了。如果两端都是Linux系统，就不需要改这个参数，改了反而速度降了，用系统默认的刚好。示例C代码： ```cpp const int nNrKb = 256; int nBuffSize = 1024 * nNrKb; int nRet = setsockopt(nSocket, SOL_SOCKET, SO_SNDBUF, (char *)&nBuffSize, sizeof(int)); nRet = setsockopt(nSocket, SOL_SOCKET, SO_RCVBUF, (char *)&nBuffSize, sizeof(int)); ```

gitea-mirror commented

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

Author

Owner

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

期望有人能在 windows 环境下按照 @missdeer 的示例修改一下 frp 的相关代码做一下验证。

@fatedier commented on GitHub (May 1, 2018): 期望有人能在 windows 环境下按照 @missdeer 的示例修改一下 frp 的相关代码做一下验证。

gitea-mirror commented

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

Author

Owner

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

我的带宽是40m，frps 服务器，frpc带宽是50m，客户端。

kcp和没用kcp我都测试过，开启kcp确实跑不满了，就像作者说的，占了一部分带宽。不过延迟确实小了。
后来我关闭了kcp功能，就能全部跑满带宽了，没有出现这个情况。

服务器是centos，客户端是windows 20008r2
不过我测试的是http的，3389 我也用过就是卡而已。当时也没在意。

@kavid commented on GitHub (May 2, 2018): 我的带宽是40m，frps 服务器，frpc带宽是50m，客户端。 kcp和没用kcp我都测试过，开启kcp确实跑不满了，就像作者说的，占了一部分带宽。不过延迟确实小了。后来我关闭了kcp功能，就能全部跑满带宽了，没有出现这个情况。服务器是centos，客户端是windows 20008r2 不过我测试的是http的，3389 我也用过就是卡而已。当时也没在意。

gitea-mirror commented

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

Author

Owner

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

@missdeer
请问你用iperf测试的方向是windows发送至linux吗？
听描述感觉像是TCP congestion control算法导致的，如果真是的话也没有好的解决办法
linux默认是cubic算法可能比windows好一些（某些情况下）

@yydcool commented on GitHub (May 3, 2018): @missdeer 请问你用iperf测试的方向是windows发送至linux吗？听描述感觉像是TCP congestion control算法导致的，如果真是的话也没有好的解决办法 linux默认是cubic算法可能比windows好一些（某些情况下）

gitea-mirror commented

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

Author

Owner

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

@yydcool
是的。以前做一个大流量relay程序，aws美东到美西，或者美国到中国，带宽怎么都跑不上去，后来发现是这个原因，在Windows侧把TCP window size改大就好了，或者全部换成Linux系统也行。

@missdeer commented on GitHub (May 3, 2018): @yydcool 是的。以前做一个大流量relay程序，aws美东到美西，或者美国到中国，带宽怎么都跑不上去，后来发现是这个原因，在Windows侧把TCP window size改大就好了，或者全部换成Linux系统也行。

gitea-mirror commented

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

Author

Owner

@shminer commented on GitHub (Aug 2, 2018):

@missdeer 如果有条件能否帮忙在win下测试下你的过程， #851 测试都是在linux下进行的，只是有一端是虚拟机，也进行过双向测试（内网linux服务器端口通过frp转发到服务器上通过服务器建立本地iperf服务直接对本地frp转发端口进行双向测试）。依然是打不到满速。两边linux服务器都是bbr拥塞。

@shminer commented on GitHub (Aug 2, 2018): @missdeer 如果有条件能否帮忙在win下测试下你的过程， #851 测试都是在linux下进行的，只是有一端是虚拟机，也进行过双向测试（内网linux服务器端口通过frp转发到服务器上通过服务器建立本地iperf服务直接对本地frp转发端口进行双向测试）。依然是打不到满速。两边linux服务器都是bbr拥塞。

gitea-mirror commented

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

Author

Owner

@thorisme commented on GitHub (Aug 2, 2018):

我的情况同@shminer（宿主机时windowsserver2016，虚拟机跑了linux），0.16.1版本没有问题，可以满速，以后的版本就不行了，frpc的设置协议是TCP，曾在虚拟的linux上跑https，速度有提升。

@thorisme commented on GitHub (Aug 2, 2018): 我的情况同@shminer（宿主机时windowsserver2016，虚拟机跑了linux），0.16.1版本没有问题，可以满速，以后的版本就不行了，frpc的设置协议是TCP，曾在虚拟的linux上跑https，速度有提升。

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Oct 23, 2018):

请不要做重复以及不能提供帮助的 comment。

@fatedier commented on GitHub (Oct 23, 2018): 请不要做重复以及不能提供帮助的 comment。

gitea-mirror commented

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

Author

Owner

@quan01994 commented on GitHub (Dec 18, 2018):

我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载
本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右，
修改注册表的就行了
注册表地址
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters
在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，
该值的范围是从0到65535，默认好像是25000
修改成60000以上，重启frp C端

@quan01994 commented on GitHub (Dec 18, 2018): 我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右，修改注册表的就行了注册表地址 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters 在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，该值的范围是从0到65535，默认好像是25000 修改成60000以上，重启frp C端

gitea-mirror commented

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

Author

Owner

@thorisme commented on GitHub (Dec 19, 2018):

我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载
本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右，
修改注册表的就行了
注册表地址
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters
在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，
该值的范围是从0到65535，默认好像是25000
修改成60000以上，重启frp C端

我客户端win2016，虚拟linux，服务端centos，改tcp，win2016没有问题，但是虚拟的linux就不行了（原来是30Mbps上传，现在只有10Mbps左右）。

@thorisme commented on GitHub (Dec 19, 2018): > 我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载 > 本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右， > 修改注册表的就行了 > 注册表地址 > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters > 在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值， > 该值的范围是从0到65535，默认好像是25000 > 修改成60000以上，重启frp C端我客户端win2016，虚拟linux，服务端centos，改tcp，win2016没有问题，但是虚拟的linux就不行了（原来是30Mbps上传，现在只有10Mbps左右）。

gitea-mirror commented

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

Author

Owner

@thorisme commented on GitHub (Jan 18, 2019):

我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载
本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右，
修改注册表的就行了
注册表地址
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters
在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，
该值的范围是从0到65535，默认好像是25000
修改成60000以上，重启frp C端

我客户端win2016，虚拟linux，服务端centos，改tcp，win2016没有问题，但是虚拟的linux就不行了（原来是30Mbps上传，现在只有10Mbps左右）。
我在想，怎样把虚拟的linux修改一下以适应win2016的tcp改变，但是能力有限，找不到修改方法。有谁能帮忙？谢谢！

@thorisme commented on GitHub (Jan 18, 2019): > > 我是C端是win10 上传速度大概是20Mb S端CentOS 2Mb下载 10Mb上载 > > 本来 200 k的东西需要 20s 加载修改大了只需要1.53秒左右， > > 修改注册表的就行了 > > 注册表地址 > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters > > 在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值， > > 该值的范围是从0到65535，默认好像是25000 > > 修改成60000以上，重启frp C端 > > 我客户端win2016，虚拟linux，服务端centos，改tcp，win2016没有问题，但是虚拟的linux就不行了（原来是30Mbps上传，现在只有10Mbps左右）。我在想，怎样把虚拟的linux修改一下以适应win2016的tcp改变，但是能力有限，找不到修改方法。有谁能帮忙？谢谢！

gitea-mirror commented

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

Author

Owner

@thorisme commented on GitHub (Apr 22, 2019):

这个问题不知道管理员大大有没有放到下次更新的日程里啊？跪求解决。

@thorisme commented on GitHub (Apr 22, 2019): 这个问题不知道管理员大大有没有放到下次更新的日程里啊？跪求解决。

gitea-mirror commented

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

Author

Owner

@quan01994 commented on GitHub (Sep 29, 2020):

出个教程，怎么改，才能让windows的效率能够达到最高。。。我的那个方法只有小部分的提升。

@quan01994 commented on GitHub (Sep 29, 2020): 出个教程，怎么改，才能让windows的效率能够达到最高。。。我的那个方法只有小部分的提升。

gitea-mirror commented

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

Author

Owner

@hyhy01 commented on GitHub (Aug 14, 2021):

一样的问题
我是windows--frps
linux--frpc
速度只有400 kb/s

@hyhy01 commented on GitHub (Aug 14, 2021): 一样的问题我是windows--frps linux--frpc 速度只有400 kb/s

gitea-mirror commented

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

Author

Owner

@Kiswelrg commented on GitHub (Sep 11, 2025):

想问下这个issue已经修复了吗，macos frpc, linux frps, 仍然是存在明显的带宽瓶颈，同时尝试了tcp/http, 都一样。换成Nps的话速度正常，但是nps没有frp好不想用。

@Kiswelrg commented on GitHub (Sep 11, 2025): 想问下这个issue已经修复了吗，macos frpc, linux frps, 仍然是存在明显的带宽瓶颈，同时尝试了tcp/http, 都一样。换成Nps的话速度正常，但是nps没有frp好不想用。

Rows
Columns

[GH-ISSUE #662] Frpc的Windows客户端穿透的转发速率只有路由器或者Linux的Frpc客户端的1/3 #517

frps.ini [common] bind_port = **** bind_udp_port = **** kcp_bind_port = **** privilege_token = ***********

frps.ini
[common]
bind_port =
bind_udp_port =
kcp_bind_port =
privilege_token = *******