[GH-ISSUE #3581] frps端口异常占用锁定

gitea-mirror commented

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

Owner

Copy link

Originally created by @SilenceLurker on GitHub (Aug 23, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3581

Bug Description

我不确定是不是在切换代理或者frpc端自己休眠导致的问题，出现的问题就是现在frps端对我原来的配置文件里对应的端口保持在一个锁定占用的状态，但是我甚至在关闭frpc端后frps依旧是保持占用状态，nmap进行扫描也是一直在解析原有配置文件内的对应端口但是没有对应服务，我只能提供frpc端的信息，frps端是租用的所以并不能确定问题发生的原因（也许重启一次frps端就可以解决？）。是否有什么方法可以从frpc端发送一个移除服务注册的方式或者别的什么让frps端解除这些端口的占用

frpc Version

0.48.0,051.3

frps Version

unknown

System Architecture

linux/amd64

Configurations

[common]
server_addr =
server_port = 7000
user =
log_file = ./frpc.log
log_level = info
tcp_mux = true
meta_token =
admin_addr = 0.0.0.0
admin_port = 7400
admin_user = admin
admin_pwd =

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 @SilenceLurker on GitHub (Aug 23, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3581 ### Bug Description 我不确定是不是在切换代理或者frpc端自己休眠导致的问题，出现的问题就是现在frps端对我原来的配置文件里对应的端口保持在一个锁定占用的状态，但是我甚至在关闭frpc端后frps依旧是保持占用状态，nmap进行扫描也是一直在解析原有配置文件内的对应端口但是没有对应服务，我只能提供frpc端的信息，frps端是租用的所以并不能确定问题发生的原因（也许重启一次frps端就可以解决？）。是否有什么方法可以从frpc端发送一个移除服务注册的方式或者别的什么让frps端解除这些端口的占用 ### frpc Version 0.48.0,051.3 ### frps Version unknown ### System Architecture linux/amd64 ### Configurations [common] server_addr = server_port = 7000 user = log_file = ./frpc.log log_level = info tcp_mux = true meta_token = admin_addr = 0.0.0.0 admin_port = 7400 admin_user = admin admin_pwd = ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

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

Author

Owner

Copy link

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

gitea-mirror referenced this issue

2026-05-05 14:45:56 -06:00

[PR #2858] [CLOSED] Fixed go vet warnings #4642

No Branch/Tag specified