[GH-ISSUE #4949] When there are too many rules on the FRP client, the client will not be able to access the HTTP/HTTPS of the FRP proxy after running for a period of time

gitea-mirror commented

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

Owner

Copy link

Originally created by @Honglei2020 on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4949

Bug Description

When there are too many rules on the FRP client, the client will not be able to access the HTTP/HTTPS of the FRP proxy after running for a period of time.
All rules can operate normally. When I randomly delete some rules, there will be no problem of being unable to access them.
There were no errors when checking the logs, only frequent connection closure prompts.

frpc Version

0.63.0

frps Version

0.63.0

System Architecture

Centos7.9

Configurations

[common]
server_addr=xxx
server_port = 8088
log_file = /var/log/frpc.log
log_level=debug
token = xxx
login_fail_exit = false

[http1]
type = https
local_ip = 127.0.0.1
local_port = 443
subdomain=ts1
use_encryption = true
use_compression = true
protocol = kcp
tcp_mux = true

n+..............

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 @Honglei2020 on GitHub (Aug 22, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4949 ### Bug Description When there are too many rules on the FRP client, the client will not be able to access the HTTP/HTTPS of the FRP proxy after running for a period of time. All rules can operate normally. When I randomly delete some rules, there will be no problem of being unable to access them. There were no errors when checking the logs, only frequent connection closure prompts. ### frpc Version 0.63.0 ### frps Version 0.63.0 ### System Architecture Centos7.9 ### Configurations [common] server_addr=xxx server_port = 8088 log_file = /var/log/frpc.log log_level=debug token = xxx login_fail_exit = false [http1] type = https local_ip = 127.0.0.1 local_port = 443 subdomain=ts1 use_encryption = true use_compression = true protocol = kcp tcp_mux = true n+.............. ### Logs _No response_ ### 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:29:24 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

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

Author

Owner

Copy link

@fatedier commented on GitHub (Aug 22, 2025):

There is no valid information to draw an appropriate conclusion. In addition, please follow the documentation as closely as possible to use the correct configuration format.

@fatedier commented on GitHub (Aug 22, 2025): There is no valid information to draw an appropriate conclusion. In addition, please follow the documentation as closely as possible to use the correct configuration format.

gitea-mirror commented

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

Author

Owner

Copy link

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

No Branch/Tag specified