[GH-ISSUE #5150] Tweak keepalive / max idle behavior to overcome brief connection outages

gitea-mirror commented

2026-05-05 14:33:19 -06:00

Owner

Originally created by @ByteCrunch on GitHub (Feb 2, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5150

Bug Description

We did some internal testing in regards to frpc's behavior when the connection to frps is lost.
Our goal is to overcome short outages (< 1 min) of the connection between frpc and frps by tweaking transport.tcpMuxKeepaliveInterval OR for quic transport.quic.keepalivePeriod / transport.quic.maxIdleTimeout to enhance the experience for legacy services with persistent connections.

We tested different increased values for these config options and blocked the incoming frpc packets on the frps host with:

sudo iptables -A INPUT -s <frpc-host> -p tcp --dport 7001 -j DROP && \
sleep 30 \
sudo iptables -D INPUT 1

However, we were not able to extend the time until frpc will close all visitor sockets to any duration longer than 30 secs. We also set these options on both frpc clients and in the frps config, but the behavior always seems to be the same - even with really high values like 270 (just for testing).

Is there any (sensible) way to tweak these options to achieve that? Also, we have issues to understand what the options actually do beside the remarks in https://github.com/fatedier/frp/blob/dev/conf/frpc_full_example.toml and some code comments we have found.

frpc Version

v0.66.0

frps Version

v0.66.0

System Architecture

linux/amd64

Configurations

frps.toml

bindAddr = "0.0.0.0"
quicBindPort = 7002
auth.method = "token"
auth.token = "..."

transport.tcpMuxKeepaliveInterval = 270

# quic protocol options
# default: transport.quic.keepalivePeriod = 10
transport.quic.keepalivePeriod = 90
# default: transport.quic.maxIdleTimeout = 30
transport.quic.maxIdleTimeout = 270

# Heartbeat configure, it's not recommended to modify the default value
# The default value of heartbeatTimeout is 90. Set negative value to disable it.
# default: transport.heartbeatTimeout = 90
transport.heartbeatTimeout = 270

frpc.toml (tcp)

serverAddr = "10.168.5.101"
serverPort = 7001
auth.method = "token"
auth.token = "..."
log.to = "/var/log/frpc.log"
# trace, debug, info, warn, error
log.level = "trace"
# default: transport.tcpMuxKeepaliveInterval = 30
transport.tcpMuxKeepaliveInterval = 270
# [[visitors]] / [[proxies]]

frpc.toml (quic)

serverAddr = "10.168.5.101"
serverPort = 7002
auth.method = "token"
auth.token = "..."
transport.protocol = "quic"
# quic protocol options
# default: transport.quic.keepalivePeriod = 10
transport.quic.keepalivePeriod = 90
# default: transport.quic.maxIdleTimeout = 30
transport.quic.maxIdleTimeout = 270
# [[visitors]] / [[proxies]]

Logs

No response

Steps to reproduce

No response

Affected area

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

Originally created by @ByteCrunch on GitHub (Feb 2, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5150 ### Bug Description We did some internal testing in regards to frpc's behavior when the connection to frps is lost. Our goal is to overcome short outages (< 1 min) of the connection between frpc and frps by tweaking `transport.tcpMuxKeepaliveInterval` OR for quic `transport.quic.keepalivePeriod` / `transport.quic.maxIdleTimeout` to enhance the experience for legacy services with persistent connections. We tested different increased values for these config options and blocked the incoming frpc packets on the frps host with: ``` sudo iptables -A INPUT -s <frpc-host> -p tcp --dport 7001 -j DROP && \ sleep 30 \ sudo iptables -D INPUT 1 ``` However, we were not able to extend the time until frpc will close all visitor sockets to any duration longer than 30 secs. We also set these options on both frpc clients and in the frps config, but the behavior always seems to be the same - even with really high values like 270 (just for testing). Is there any (sensible) way to tweak these options to achieve that? Also, we have issues to understand what the options actually do beside the remarks in https://github.com/fatedier/frp/blob/dev/conf/frpc_full_example.toml and some code comments we have found. ### frpc Version v0.66.0 ### frps Version v0.66.0 ### System Architecture linux/amd64 ### Configurations frps.toml ```toml bindAddr = "0.0.0.0" quicBindPort = 7002 auth.method = "token" auth.token = "..." transport.tcpMuxKeepaliveInterval = 270 # quic protocol options # default: transport.quic.keepalivePeriod = 10 transport.quic.keepalivePeriod = 90 # default: transport.quic.maxIdleTimeout = 30 transport.quic.maxIdleTimeout = 270 # Heartbeat configure, it's not recommended to modify the default value # The default value of heartbeatTimeout is 90. Set negative value to disable it. # default: transport.heartbeatTimeout = 90 transport.heartbeatTimeout = 270 ``` frpc.toml (tcp) ```toml serverAddr = "10.168.5.101" serverPort = 7001 auth.method = "token" auth.token = "..." log.to = "/var/log/frpc.log" # trace, debug, info, warn, error log.level = "trace" # default: transport.tcpMuxKeepaliveInterval = 30 transport.tcpMuxKeepaliveInterval = 270 # [[visitors]] / [[proxies]] ``` frpc.toml (quic) ```toml serverAddr = "10.168.5.101" serverPort = 7002 auth.method = "token" auth.token = "..." transport.protocol = "quic" # quic protocol options # default: transport.quic.keepalivePeriod = 10 transport.quic.keepalivePeriod = 90 # default: transport.quic.maxIdleTimeout = 30 transport.quic.maxIdleTimeout = 270 # [[visitors]] / [[proxies]] ``` ### Logs _No response_ ### Steps to reproduce _No response_ ### Affected area - [ ] Docs - [ ] Installation - [x] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:33:19 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:33:22 -06:00

Author

Owner

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