[GH-ISSUE #4032] Using frp v0.52.3 keeps showing login server failure: connection write timeout

gitea-mirror commented

2026-05-05 14:03:50 -06:00

Owner

Copy link

Originally created by @M3GUMI on GitHub (Feb 28, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4032

Bug Description

The server logs are not receiving frp requests from the client, and the client logs are reporting connection write timeout. when using the tcp protocol or changing enableTLS to false, I still can't connect. I tested the server with telnet and port 7000 is open.

frpc Version

0.52.3

frps Version

0.52.3

System Architecture

linux/amd64

Configurations

frps:
bindPort = 7000
kcpBindPort = 7000

frpc:
serverAddr = "x.x.x.x"
serverPort = 7000
enableTLS = true
transport.protocol = "kcp"

proxies
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = xxx

Logs

server:
[root.go:102] frps uses config file: frps.toml
[service.go:200] frps tcp listen on 0.0.0.0:7000
[service.go:210] frps kcp listen on udp 0.0.0.0:7000
[root.go:111] frps started successfully

client:
[root.go:139] start frpc service for config file [frpc.toml]
[service.go:131] login to server failed: connection write timeout
[root.go:154] frpc service for config file [frpc.toml] stopped

It doesn't look like the server is receiving frp requests from the client. It also still doesn't connect when I use the tcp protocol, and when I change enableTLS to false. I tested the server with telnet and port 7000 is open.

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 @M3GUMI on GitHub (Feb 28, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4032 ### Bug Description The server logs are not receiving frp requests from the client, and the client logs are reporting connection write timeout. when using the tcp protocol or changing enableTLS to false, I still can't connect. I tested the server with telnet and port 7000 is open. ### frpc Version 0.52.3 ### frps Version 0.52.3 ### System Architecture linux/amd64 ### Configurations frps: bindPort = 7000 kcpBindPort = 7000 -------------------------------------- frpc: serverAddr = "x.x.x.x" serverPort = 7000 enableTLS = true transport.protocol = "kcp" [[proxies]] name = "ssh" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = xxx ### Logs server: [root.go:102] frps uses config file: frps.toml [service.go:200] frps tcp listen on 0.0.0.0:7000 [service.go:210] frps kcp listen on udp 0.0.0.0:7000 [root.go:111] frps started successfully ------------------------------------------- client: [root.go:139] start frpc service for config file [frpc.toml] [service.go:131] login to server failed: connection write timeout [root.go:154] frpc service for config file [frpc.toml] stopped ------------------------------------------- It doesn't look like the server is receiving frp requests from the client. It also still doesn't connect when I use the tcp protocol, and when I change enableTLS to false. I tested the server with telnet and port 7000 is open. ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:03:50 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:03:53 -06:00

Author

Owner

Copy link

@xqzr commented on GitHub (Mar 1, 2024):

根据你给出的配置，需要防火墙开放 UDP 7000。
telnet 测试通过，是因为它 TCP 7000

@xqzr commented on GitHub (Mar 1, 2024): 根据你给出的配置，需要防火墙开放 **UDP** 7000。 `telnet` 测试通过，是因为它 **TCP** 7000

gitea-mirror commented

2026-05-05 14:03:54 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Mar 23, 2024):

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

@github-actions[bot] commented on GitHub (Mar 23, 2024): Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

gitea-mirror referenced this issue

2026-05-05 14:46:54 -06:00

[PR #3192] [MERGED] Support OIDC scope parameter #4693

gitea-mirror referenced this issue

2026-05-05 14:47:04 -06:00

[PR #3218] [MERGED] release v0.46.0 #4701

No Branch/Tag specified