[GH-ISSUE #3277] [Feature Request] Any way to support kick off client connection from server? #2627

New issue

Closed

opened 2026-05-05 13:41:45 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 13:41:45 -06:00

Owner

Originally created by @kom0055 on GitHub (Jan 31, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3277

Describe the feature request

Is there any way to support kick off client connection from sever? I mean in server control plane

有什么接口可以在服务端让已连接的客户端下线么？

Describe alternatives you've considered

If not, might provide a set of control interfaces as well

Affected area

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

Originally created by @kom0055 on GitHub (Jan 31, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3277 ### Describe the feature request Is there any way to support kick off client connection from sever? I mean in server control plane 有什么接口可以在服务端让已连接的客户端下线么？ ### Describe alternatives you've considered If not, might provide a set of control interfaces as well ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [X] Server Plugin - [X] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:41:45 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:41:48 -06:00

Author

Owner

@Becods commented on GitHub (Jan 31, 2023):

# for CentOS
yum -y install dsniff --enablerepo=epel

# for Ubuntu
sudo apt-get install dsniff

# 7000 是frp的连接端口
netstat -n|grep 7000

# "-i" 后面的bond0是网卡，可以通过ifconfig找到
# "-9" 表示关闭连接的迫切程度，越大表示越强制，默认是3
# "port 54774" 是指定连接的表达式，这个和iptables差不多
tcpkill -i eth0 -9 port 54774

建议配合 Killcx 使用

@Becods commented on GitHub (Jan 31, 2023): ``` # for CentOS yum -y install dsniff --enablerepo=epel # for Ubuntu sudo apt-get install dsniff ``` ``` # 7000 是frp的连接端口 netstat -n|grep 7000 ``` ``` # "-i" 后面的bond0是网卡，可以通过ifconfig找到 # "-9" 表示关闭连接的迫切程度，越大表示越强制，默认是3 # "port 54774" 是指定连接的表达式，这个和iptables差不多 tcpkill -i eth0 -9 port 54774 ``` 建议配合 [Killcx](https://killcx.sourceforge.net/) 使用

gitea-mirror commented

2026-05-05 13:41:49 -06:00

Author

Owner

@kom0055 commented on GitHub (Jan 31, 2023):

# for CentOS
yum -y install dsniff --enablerepo=epel

# for Ubuntu
sudo apt-get install dsniff

# 7000 是frp的连接端口
netstat -n|grep 7000

# "-i" 后面的bond0是网卡，可以通过ifconfig找到
# "-9" 表示关闭连接的迫切程度，越大表示越强制，默认是3
# "port 54774" 是指定连接的表达式，这个和iptables差不多
tcpkill -i eth0 -9 port 54774

建议配合 Killcx 使用

感觉这样不是很优雅。。
我们是运维方向的业务，用K8S扩缩容保证高可用。为什么需要下线client到server的连接，是因为frp这一套实际上是有状态的应用，在扩容的过程中如果不断开已有的连接，新扩容出来的Pod上可能很长时间一个连接也没有，除非某次连接断开，客户端重新建立tunnel。

我个人认为，实际上我们目前的依赖关系是 app->frp->os，直接从app->os 可能会使得项目维护慢慢变得困难。因为app中看到的是业务上的一个连接id 不需要关心暴露的端口是啥。

不过这个我也会去尝试，我们目前是准备在容器里面通过frp sidecar形式做跨集群NAT穿越。

我有几个想法

frps 有接口能提供下线某个客户端的连接
定时frpc侧断开重连，比如刷新配置之类的操作，或者有更友好的接口。（目前感觉定时客户端重连更可行一点）

大佬们觉得有没有这种类似的场景或者需求的必要？或者有其他好的解决方案

另外如果有需要做的话，方案讨论完我可以帮把手一起实现，还挺想贡献些代码的，哈哈

@kom0055 commented on GitHub (Jan 31, 2023): > ``` > # for CentOS > yum -y install dsniff --enablerepo=epel > > # for Ubuntu > sudo apt-get install dsniff > ``` > > ``` > # 7000 是frp的连接端口 > netstat -n|grep 7000 > ``` > > ``` > # "-i" 后面的bond0是网卡，可以通过ifconfig找到 > # "-9" 表示关闭连接的迫切程度，越大表示越强制，默认是3 > # "port 54774" 是指定连接的表达式，这个和iptables差不多 > tcpkill -i eth0 -9 port 54774 > ``` > > 建议配合 [Killcx](https://killcx.sourceforge.net/) 使用感觉这样不是很优雅。。我们是运维方向的业务，用K8S扩缩容保证高可用。为什么需要下线client到server的连接，是因为frp这一套实际上是有状态的应用，在扩容的过程中如果不断开已有的连接，新扩容出来的Pod上可能很长时间一个连接也没有，除非某次连接断开，客户端重新建立tunnel。我个人认为，实际上我们目前的依赖关系是 app->frp->os，直接从app->os 可能会使得项目维护慢慢变得困难。因为app中看到的是业务上的一个连接id 不需要关心暴露的端口是啥。不过这个我也会去尝试，我们目前是准备在容器里面通过frp sidecar形式做跨集群NAT穿越。我有几个想法 1. frps 有接口能提供下线某个客户端的连接 2. 定时frpc侧断开重连，比如刷新配置之类的操作，或者有更友好的接口。（目前感觉定时客户端重连更可行一点）大佬们觉得有没有这种类似的场景或者需求的必要？或者有其他好的解决方案另外如果有需要做的话，方案讨论完我可以帮把手一起实现，还挺想贡献些代码的，哈哈

gitea-mirror commented

2026-05-05 13:41:50 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 31, 2023):

@kom0055 想法挺好，但是并不打算在当前的版本里引入相关的能力了。像高可用，水平扩展等等并不是只有这一点，而是可能要考虑一个完整的设计。后面可以在 v2 里做的更好。

@fatedier commented on GitHub (Jan 31, 2023): @kom0055 想法挺好，但是并不打算在当前的版本里引入相关的能力了。像高可用，水平扩展等等并不是只有这一点，而是可能要考虑一个完整的设计。后面可以在 v2 里做的更好。

gitea-mirror commented

2026-05-05 13:41:51 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 3, 2023):

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

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