[GH-ISSUE #4840] quic is work,bug tcp and wss not work

gitea-mirror commented

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

Owner

Originally created by @chunyuforka on GitHub (Jun 18, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4840

Bug Description

Using the QUIC protocol works, but TCP, WSS, and WebSocket all fail—even with TLS enabled. We suspect the traffic is being blocked by a firewall. The problem with QUIC is that the datacenter may impose restrictions on UDP: bandwidth is limited to just 1 Mb, and when we tested UDP with iperf3 we saw a 97% packet loss. Therefore, we still need a solution that works over TCP. Our FRPS security group is already configured to allow both TCP and UDP from 0.0.0.0/0, and we can successfully telnet to the port.

frpc Version

0.56.0

frps Version

0.56.0

System Architecture

linux/amd64

Configurations

frps.toml

bindPort = 17300
transport.tls.force = false
#transport.tls.force = true
#transport.tls.certFile = "frps.crt"
#transport.tls.keyFile = "frps.key"
#transport.tls.trustedCaFile = "ca.crt"

auth.method = "token"
auth.token = "xxxxx"

quicBindPort = 17300
transport.maxPoolCount = 20
log.level = "trace"
log.maxDays = 3
allowPorts = [
  { start = 25900, end = 25990 }
]

frpc.toml

webServer.addr = "127.0.0.1"
webServer.port = 7400

serverAddr = "1.2.3.4"
serverPort = 17300
transport.protocol = "quic"
auth.method = "token"
auth.token = "xxxxx"
transport.tls.enable = false

log.level = "info"
log.maxDays = 7
transport.poolCount = 16

[[proxies]]
name = "ssh-web-1"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 25901

Logs

If switched to TCP mode, the client will remain stuck in a continuous connection-attempt loop.

root@web-1:/etc/frpc# frpc -c frpc-2.toml
2025-06-18 19:21:38.035 [I] [sub/root.go:142] start frpc service for config file [frpc-2.toml]
2025-06-18 19:21:38.035 [I] [client/service.go:294] try to connect to server...

Steps to reproduce

When deployed over TCP, it works initially but then suddenly stops working after about three days.

Affected area

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

Originally created by @chunyuforka on GitHub (Jun 18, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4840 ### Bug Description Using the QUIC protocol works, but TCP, WSS, and WebSocket all fail—even with TLS enabled. We suspect the traffic is being blocked by a firewall. The problem with QUIC is that the datacenter may impose restrictions on UDP: bandwidth is limited to just 1 Mb, and when we tested UDP with iperf3 we saw a 97% packet loss. Therefore, we still need a solution that works over TCP. Our FRPS security group is already configured to allow both TCP and UDP from 0.0.0.0/0, and we can successfully `telnet` to the port. ### frpc Version 0.56.0 ### frps Version 0.56.0 ### System Architecture linux/amd64 ### Configurations frps.toml ```shell bindPort = 17300 transport.tls.force = false #transport.tls.force = true #transport.tls.certFile = "frps.crt" #transport.tls.keyFile = "frps.key" #transport.tls.trustedCaFile = "ca.crt" auth.method = "token" auth.token = "xxxxx" quicBindPort = 17300 transport.maxPoolCount = 20 log.level = "trace" log.maxDays = 3 allowPorts = [ { start = 25900, end = 25990 } ] ``` frpc.toml ```shell webServer.addr = "127.0.0.1" webServer.port = 7400 serverAddr = "1.2.3.4" serverPort = 17300 transport.protocol = "quic" auth.method = "token" auth.token = "xxxxx" transport.tls.enable = false log.level = "info" log.maxDays = 7 transport.poolCount = 16 [[proxies]] name = "ssh-web-1" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 25901 ``` ### Logs If switched to TCP mode, the client will remain stuck in a continuous connection-attempt loop. ``` root@web-1:/etc/frpc# frpc -c frpc-2.toml 2025-06-18 19:21:38.035 [I] [sub/root.go:142] start frpc service for config file [frpc-2.toml] 2025-06-18 19:21:38.035 [I] [client/service.go:294] try to connect to server... ``` ### Steps to reproduce When deployed over TCP, it works initially but then suddenly stops working after about three days. ### Affected area - [x] Docs - [x] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Jun 20, 2025):

You can try combining other tools to solve similar network issues.

@fatedier commented on GitHub (Jun 20, 2025): You can try combining other tools to solve similar network issues.

gitea-mirror commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Jul 5, 2025):

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 (Jul 5, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror commented

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

Author

Owner

@chunyuforka commented on GitHub (Jul 8, 2025):

After encrypting the TCP connection of frp with v2ray, the connection is stable and available, and the bandwidth remains above 10Mb.

@chunyuforka commented on GitHub (Jul 8, 2025): After encrypting the TCP connection of frp with v2ray, the connection is stable and available, and the bandwidth remains above 10Mb.

gitea-mirror referenced this issue

2026-05-05 14:49:41 -06:00

[PR #3821] [MERGED] ssh: return informations to client #4838