[GH-ISSUE #864] Slow throughput #683

New issue

Closed

opened 2026-05-05 12:26:29 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @qricambi on GitHub (Aug 1, 2018).
Original GitHub issue: https://github.com/fatedier/frp/issues/864

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

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

Configures you used:
[common]
server_addr =
server_port = 7000
tcp_mux = false ; with or without this one

[b35444c3-a35f-4580-9d33-61a96a0b8cd0]
type = tcp
remote_port = 9090
local_ip = 127.0.0.1
local_port = 62000

Steps to reproduce the issue:
One the 62000 port I have an http proxy, and when I connect directly to it the download speed using fast.com is RIGHT.
But when I proxy through the server public IP I peak at 2.6 Mb/s and it seams that this 2Mb/s is the limit

Describe the results you expected:
I'm testing this with a google server that has considerably more download or upload bandwidth so I would like to recieve the same download speed that I have without frp.

What do you think is the problem, I would love even to have a hint to where to look in the code

Originally created by @qricambi on GitHub (Aug 1, 2018). Original GitHub issue: https://github.com/fatedier/frp/issues/864 **What version of frp are you using (./frpc -v or ./frps -v)?** v0.20.0 **What operating system and processor architecture are you using (`go env`)?** Windows amd64 **Configures you used:** [common] server_addr = server_port = 7000 tcp_mux = false ; with or without this one [b35444c3-a35f-4580-9d33-61a96a0b8cd0] type = tcp remote_port = 9090 local_ip = 127.0.0.1 local_port = 62000 **Steps to reproduce the issue:** One the 62000 port I have an http proxy, and when I connect directly to it the download speed using fast.com is RIGHT. But when I proxy through the server public IP I peak at 2.6 Mb/s and it seams that this 2Mb/s is the limit **Describe the results you expected:** I'm testing this with a google server that has considerably more download or upload bandwidth so I would like to recieve the same download speed that I have without frp. What do you think is the problem, I would love even to have a hint to where to look in the code

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

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

Duplicate of #851 & #662

@fatedier commented on GitHub (Aug 1, 2018): Duplicate of #851 & #662

gitea-mirror commented

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

Author

Owner

@qricambi commented on GitHub (Aug 1, 2018):

Sorry man, can't read chinese :(

@qricambi commented on GitHub (Aug 1, 2018): Sorry man, can't read chinese :(

gitea-mirror commented

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

Author

Owner

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

Please keep watching #851, it's a same issue.
I will reply it if i have come to a conclusion, by the way, i am busy doing other projects and i'm not sure when it cloud be solved.

@fatedier commented on GitHub (Aug 1, 2018): Please keep watching #851, it's a same issue. I will reply it if i have come to a conclusion, by the way, i am busy doing other projects and i'm not sure when it cloud be solved.

gitea-mirror commented

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

Author

Owner

@qricambi commented on GitHub (Aug 1, 2018):

I rechecked my data and I think that my problem is not about throughput but about latency.
If I proxy a curl GET to google.com I got a response in about 1500ms.
Using a proxy chain passing exactly to the same hosts and clients the request take at most 600ms.

Do you think that tcp is slowing things down, could using udp better these performance issues?

@qricambi commented on GitHub (Aug 1, 2018): I rechecked my data and I think that my problem is not about throughput but about latency. If I proxy a curl GET to google.com I got a response in about 1500ms. Using a proxy chain passing exactly to the same hosts and clients the request take at most 600ms. Do you think that tcp is slowing things down, could using udp better these performance issues?