[GH-ISSUE #5078] port range proxies definition partly gives "start error: status not wait start" after frpc is connected

Originally created by @ByteCrunch on GitHub (Nov 28, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/5078 ### Bug Description I have an issue after frpc is connected to the server with the following configuration: ``` [...] [[visitors]] name = "prdkeycloak" type = "stcp" secretKey = "1234567890foobarUser" serverName = "prdkeycloak" bindAddr = "0.0.0.0" bindPort = 5443 {{- range $i, $port := parseNumberRange "49500-50500" }} [[proxies]] name = "zzdynprt-test-{{ $port }}" type = "stcp" secretKey = "srEbpntamhrlCE5d1TBj1ZHweVSq1QMhSRznshdle-Y" localIP = "192.168.5.13" localPort = {{ $port }} {{- end }} ``` After successful connection to the frps, I get partly success logs for the port range definition, and also lots of errors: ``` [...] 2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50498] start proxy success 2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50496] start proxy success 2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50499] start proxy success 2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50500] start proxy success 2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50407] start error: status not wait start, ignore start message 2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50424] start error: status not wait start, ignore start message 2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50438] start error: status not wait start, ignore start message 2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50435] start error: status not wait start, ignore start message [...] ``` If I comment out the range definition block at startup, start frpc and let it connect, uncomment the block again and reload the configuration with `/opt/frp/bin/frpc reload -c /opt/frp/etc/frpc.toml` I don't see any errors. Is there a general limitation how big a port range can be at startup? Kind regards Manuel ### frpc Version v0.65.0 ### frps Version v0.64.0 ### System Architecture linux/amd64 ### Configurations ``` serverAddr = "x.x.x.x" serverPort = 9000 transport.tcpMux = true # multiplex connections log.level = "debug" # webserver needed for hot reload feature webServer.addr = "127.0.0.1" webServer.port = 7400 auth.method = "token" auth.tokenSource.type = "file" auth.tokenSource.file.path = "/mnt/secrets/token" loginFailExit = false [[visitors]] name = "test" type = "stcp" secretKey = "1234567890foobarUser" serverName = "test" bindAddr = "0.0.0.0" bindPort = 5443 {{- range $i, $port := parseNumberRange "49500-50500" }} [[proxies]] name = "zzdynprt-test-{{ $port }}" type = "stcp" secretKey = "srEbpntamhrlCE5d1TBj1ZHweVSq1QMhSRznshdle-Y" localIP = "192.168.5.13" localPort = {{ $port }} {{- end }} ``` ### Steps to reproduce 1. Startup frpc and wait for connection to frps 2. after lots of "start proxy success" messages for the defined range, lots of error lines will appear ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [x] Others

gitea-mirror commented

2026-05-05 14:32:13 -06:00

Owner

Originally created by @ByteCrunch on GitHub (Nov 28, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/5078

Bug Description

I have an issue after frpc is connected to the server with the following configuration:

[...]

[[visitors]]
name = "prdkeycloak"
type = "stcp"
secretKey = "1234567890foobarUser"
serverName = "prdkeycloak"
bindAddr = "0.0.0.0"
bindPort = 5443

{{- range $i, $port := parseNumberRange "49500-50500" }}
[[proxies]]
name = "zzdynprt-test-{{ $port }}"
type = "stcp"
secretKey = "srEbpntamhrlCE5d1TBj1ZHweVSq1QMhSRznshdle-Y"
localIP = "192.168.5.13"
localPort = {{ $port }}
{{- end }}

After successful connection to the frps, I get partly success logs for the port range definition, and also lots of errors:

[...]
2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50498] start proxy success                                                                                   
2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50496] start proxy success                                                                                   
2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50499] start proxy success                                                                                   
2025-11-28 09:02:24.227 [I] [client/control.go:172] [1e63172435c75768] [zzdynprt-test-50500] start proxy success                                                                                   
2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50407] start error: status not wait start, ignore start message                                              
2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50424] start error: status not wait start, ignore start message                                              
2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50438] start error: status not wait start, ignore start message                                              
2025-11-28 09:02:24.227 [W] [client/control.go:170] [1e63172435c75768] [zzdynprt-test-50435] start error: status not wait start, ignore start message
[...]

If I comment out the range definition block at startup, start frpc and let it connect, uncomment the block again and reload the configuration with /opt/frp/bin/frpc reload -c /opt/frp/etc/frpc.toml I don't see any errors.

Is there a general limitation how big a port range can be at startup?

Kind regards
Manuel

frpc Version

v0.65.0

frps Version

v0.64.0

System Architecture

linux/amd64

Configurations

serverAddr = "x.x.x.x"
serverPort = 9000
transport.tcpMux = true # multiplex connections

log.level = "debug"

# webserver needed for hot reload feature
webServer.addr = "127.0.0.1"
webServer.port = 7400

auth.method = "token"
auth.tokenSource.type = "file"
auth.tokenSource.file.path = "/mnt/secrets/token"

loginFailExit = false

[[visitors]]
name = "test"
type = "stcp"
secretKey = "1234567890foobarUser"
serverName = "test"
bindAddr = "0.0.0.0"
bindPort = 5443

{{- range $i, $port := parseNumberRange "49500-50500" }}
[[proxies]]
name = "zzdynprt-test-{{ $port }}"
type = "stcp"
secretKey = "srEbpntamhrlCE5d1TBj1ZHweVSq1QMhSRznshdle-Y"
localIP = "192.168.5.13"
localPort = {{ $port }}
{{- end }}

Steps to reproduce

Startup frpc and wait for connection to frps
after lots of "start proxy success" messages for the defined range, lots of error lines will appear
...

Affected area

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

gitea-mirror

closed this issue
added the
lifecycle/stale
label

2026-05-05 14:32:16 -06:00

Author

@fatedier commented on GitHub (Nov 28, 2025):

When a large number of proxies start simultaneously, there may be some delays and errors, but they should eventually recover automatically.

@fatedier commented on GitHub (Nov 28, 2025): When a large number of proxies start simultaneously, there may be some delays and errors, but they should eventually recover automatically.

2026-05-05 14:32:17 -06:00

@ByteCrunch commented on GitHub (Dec 9, 2025):

It seems that it will in fact resolve itself after 5-30 minutes. There are also accompanying errors in the FRP server logs:

[server/control.go:394] [66ec09239cf50970] new proxy [zzdynprt-test-50437] type [stcp] error: proxy [zzdynprt-test-50437] already exists

I guess it takes some time for the proxy or registration of a proxy is removed properly if a client didn't disconnect gracefully.

@ByteCrunch commented on GitHub (Dec 9, 2025): It seems that it will in fact resolve itself after 5-30 minutes. There are also accompanying errors in the FRP server logs: [server/control.go:394] [66ec09239cf50970] new proxy [zzdynprt-test-50437] type [stcp] error: proxy [zzdynprt-test-50437] already exists I guess it takes some time for the proxy or registration of a proxy is removed properly if a client didn't disconnect gracefully.

2026-05-05 14:32:18 -06:00

@fatedier commented on GitHub (Dec 9, 2025):

Batch registering a large number of ports is not the recommended way to use this tool, but we will consider some optimizations for this scenario in the future.

@fatedier commented on GitHub (Dec 9, 2025): Batch registering a large number of ports is **not** the recommended way to use this tool, but we will consider some optimizations for this scenario in the future.

@github-actions[bot] commented on GitHub (Dec 24, 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 (Dec 24, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

Rows
Columns

[GH-ISSUE #5078] port range proxies definition partly gives "start error: status not wait start" after frpc is connected #3990