[GH-ISSUE #5224] FRP TCP丢包/重传严重

gitea-mirror commented

2026-05-05 14:34:24 -06:00

Owner

Copy link

Originally created by @chongchong721 on GitHub (Mar 8, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5224

Bug Description

有一台同城的阿里云服务器A和一台内网机器B

A-B间网络情况良好

A/B之间的ping RTT是8ms，互相的MTR也是8ms，都没有丢包。
使用tcp nc测试正常。
直接使用ssh从B链接A延迟正常
先从B ssh到 A使用反向端口转发22，再从A ssh回 B 延迟正常

A/B分别用frp官方的docker做了内网穿透。所有设置均为默认

现在通过frp的端口在A上ssh B（127.0.0.1:frp端口）。同时使用
ss -ti '( sport = :7000 or dport = :7000 or sport = :22022 or dport = :22022 )'
观察服务器A 7000端口的情况:

链路基线 RTT（ss minrtt)：7 ms
该异常 TCP 流实时 RTT：平均 347 ms，波动 541 ms
TCP 重传超时（RTO）：3012 ms
拥塞窗口（cwnd）：2
重传字节数：40005 / 79884，约 50.1%

tcpdump也显示重传严重。

不知道这是阿里云的问题还是frp的问题？

已经尝试过QUIC和禁用tcpmux，没有效果

frpc Version

0.67

frps Version

0.67

System Architecture

linux/amd64

Configurations

frpc：

serverAddr = "xxxxxx"
serverPort = 7000

auth.method = "token"
auth.token = "123456"

transport.tcpMux = false

proxies
name = "ubuntu-ssh-tcp-test"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 22022

frps：

bindPort = 7000

auth.method = "token"
auth.token = "123456"

transport.tcpMux = false

Logs

No response

Steps to reproduce

...

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @chongchong721 on GitHub (Mar 8, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5224 ### Bug Description 有一台同城的阿里云服务器A和一台内网机器B A-B间网络情况良好 - A/B之间的ping RTT是8ms，互相的MTR也是8ms，都没有丢包。 - 使用tcp nc测试正常。 - 直接使用ssh从B链接A延迟正常 - 先从B ssh到 A使用反向端口转发22，再从A ssh回 B 延迟正常 A/B分别用frp官方的docker做了内网穿透。所有设置均为默认现在通过frp的端口在A上ssh B（127.0.0.1:frp端口）。同时使用 `ss -ti '( sport = :7000 or dport = :7000 or sport = :22022 or dport = :22022 )'` 观察服务器A 7000端口的情况: - 链路基线 RTT（ss minrtt)：7 ms - 该异常 TCP 流实时 RTT：平均 347 ms，波动 541 ms - TCP 重传超时（RTO）：3012 ms - 拥塞窗口（cwnd）：2 - 重传字节数：40005 / 79884，约 50.1% tcpdump也显示重传严重。不知道这是阿里云的问题还是frp的问题？已经尝试过QUIC和禁用tcpmux，没有效果 ### frpc Version 0.67 ### frps Version 0.67 ### System Architecture linux/amd64 ### Configurations frpc： serverAddr = "xxxxxx" serverPort = 7000 auth.method = "token" auth.token = "123456" transport.tcpMux = false [[proxies]] name = "ubuntu-ssh-tcp-test" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 22022 frps： bindPort = 7000 auth.method = "token" auth.token = "123456" transport.tcpMux = false ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [x] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:34:24 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:34:26 -06:00

Author

Owner

Copy link

@kilo-code-bot[bot] commented on GitHub (Mar 8, 2026):

The reporter is asking whether severe TCP retransmission and latency observed when SSHing through frp is caused by frp or the cloud/network environment, and wants troubleshooting guidance. They provide measurements, configs, and comparative tests showing normal behavior outside frp.

This response was generated by Kilo Auto-Triage and may not be fully accurate. Please verify the information independently.

@kilo-code-bot[bot] commented on GitHub (Mar 8, 2026): The reporter is asking whether severe TCP retransmission and latency observed when SSHing through frp is caused by frp or the cloud/network environment, and wants troubleshooting guidance. They provide measurements, configs, and comparative tests showing normal behavior outside frp. *This response was generated by Kilo Auto-Triage and may not be fully accurate. Please verify the information independently.*

gitea-mirror commented

2026-05-05 14:34:27 -06:00

Author

Owner

Copy link

@Wronthyou-Emme commented on GitHub (Mar 14, 2026):

如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。

@Wronthyou-Emme commented on GitHub (Mar 14, 2026): 如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。

gitea-mirror commented

2026-05-05 14:34:28 -06:00

Author

Owner

Copy link

@chenyincq commented on GitHub (Mar 18, 2026):

升级到0.67以后导致现在这边经常重连，以前的版本基本上没出现。感觉是0.67引入了bug，目前我也排查不了

@chenyincq commented on GitHub (Mar 18, 2026): 升级到0.67以后导致现在这边经常重连，以前的版本基本上没出现。感觉是0.67引入了bug，目前我也排查不了

gitea-mirror commented

2026-05-05 14:34:29 -06:00

Author

Owner

Copy link

@chenyincq commented on GitHub (Mar 18, 2026):

如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。

应该还是不正常的，我是升级到0.67后出现的，我考虑回滚了。

@chenyincq commented on GitHub (Mar 18, 2026): > 如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。应该还是不正常的，我是升级到0.67后出现的，我考虑回滚了。

gitea-mirror commented

2026-05-05 14:34:29 -06:00

Author

Owner

Copy link

@chongchong721 commented on GitHub (Mar 18, 2026):

如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。

用的阿里云的个人99一年的那个服务器。我这边测试用Wireguard组网的话就正常，应该不会是服务器网络性能的原因

@chongchong721 commented on GitHub (Mar 18, 2026): > 如果你是阿里云的锐捷系列的轻量应用服务器，这是正常的。因为这个系列就是超卖的，共用200Mbps的网络。用的阿里云的个人99一年的那个服务器。我这边测试用Wireguard组网的话就正常，应该不会是服务器网络性能的原因

gitea-mirror commented

2026-05-05 14:34:29 -06:00

Author

Owner

Copy link

@chenyincq commented on GitHub (Mar 18, 2026):

我用的就是99一年2m网速那个服务器。更新到0.67后。进行ssh即tcp链接异常。

@chenyincq commented on GitHub (Mar 18, 2026): 我用的就是99一年2m网速那个服务器。更新到0.67后。进行ssh即tcp链接异常。

gitea-mirror commented

2026-05-05 14:34:30 -06:00

Author

Owner

Copy link

@dengxiwang commented on GitHub (Mar 19, 2026):

确实，我回退到了0.66.0，好多了

@dengxiwang commented on GitHub (Mar 19, 2026): 确实，我回退到了0.66.0，好多了

gitea-mirror commented

2026-05-05 14:34:30 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Apr 3, 2026):

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

@github-actions[bot] commented on GitHub (Apr 3, 2026): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror referenced this issue

2026-05-05 14:51:01 -06:00

[PR #4060] [MERGED] bump version #4906

No Branch/Tag specified