[GH-ISSUE #4709] [Feature Request] API to kill tunnels #3719

New issue

Closed

opened 2026-05-05 14:23:08 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 14:23:08 -06:00

Owner

Originally created by @mobilemodula on GitHub (Mar 13, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4709

Description

Hi, at production we got lots of issues about internet connection drops, machine being turned-off, power loss... Most of the time reverse tunnels stuck open until timeout (2h is the default value) close them, I really don't wanna decrease this value because it will generate a lot of bandwhich because I use something about 300 connections. In my mind it would be ideal to:

try to reopen a connection, then:
A: it opens fine, ok 👍
B: it "name/ID" is already open, gonna send a call to kill this tunnel and then I can open it 👍

It's possible to be my fault, but at my comprehension it would be so useful to interact like that with frps, if you have another ideia to solve this kinda scenario I would be grateful to listen. Thanks for your attention!

Alternatives I've considered

Restarting the server whe needed
Decreasing timeout values and increase bandwhich usage by that

Affected area

Developer Infrastructure

Originally created by @mobilemodula on GitHub (Mar 13, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4709 ### Description Hi, at production we got lots of issues about internet connection drops, machine being turned-off, power loss... Most of the time reverse tunnels stuck open until timeout (2h is the default value) close them, I really don't wanna decrease this value because it will generate a lot of bandwhich because I use something about 300 connections. In my mind it would be ideal to: 1. try to reopen a connection, then: A: it opens fine, ok 👍 B: it "name/ID" is already open, gonna send a call to kill this tunnel and then I can open it 👍 It's possible to be my fault, but at my comprehension it would be so useful to interact like that with frps, if you have another ideia to solve this kinda scenario I would be grateful to listen. Thanks for your attention! ### Alternatives I've considered 1. Restarting the server whe needed 2. Decreasing timeout values and increase bandwhich usage by that ### Affected area - [x] Developer Infrastructure

gitea-mirror

2026-05-05 14:23:08 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:23:11 -06:00

Author

Owner

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

gitea-mirror referenced this issue

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

[PR #3719] [MERGED] admin user not convert in INI #4814

gitea-mirror referenced this issue

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

[PR #3722] [MERGED] bump version #4815