[GH-ISSUE #2459] 如果多个客户端同时使用一个子域名，有没办法自动关闭报冲突的客户端【frpc】 #1953

New issue

Closed

opened 2026-05-05 13:15:23 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 13:15:23 -06:00

Owner

Originally created by @catchfishday on GitHub (Jun 25, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2459

The solution you want

如果同一个端口号或者子域名多个客户端同时使用，有没有办法当客户端检测到冲突是自动关闭进程，避免服务端和客户端一直写入冲突日志。

Alternatives considered

最好通过服务端控制，自动屏蔽冲突达到一定次数了的客户端，或者客户单配置文件加入相关参数，当冲突达到多少次了自动结束当前进程。

How to implement this function

Application scenarios of this function

Originally created by @catchfishday on GitHub (Jun 25, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2459  **The solution you want**  如果同一个端口号或者子域名多个客户端同时使用，有没有办法当客户端检测到冲突是自动关闭进程，避免服务端和客户端一直写入冲突日志。 **Alternatives considered**  最好通过服务端控制，自动屏蔽冲突达到一定次数了的客户端，或者客户单配置文件加入相关参数，当冲突达到多少次了自动结束当前进程。 **How to implement this function**  **Application scenarios of this function**

gitea-mirror

2026-05-05 13:15:23 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:15:26 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 8, 2021):

一个客户端并非一定只有一个 proxy，所以出现冲突就退出不是很合理。

你可以理解客户端的配置是声明式的，只要你配置了，就会不断尝试去将当前状态和配置项匹配。你可以尝试，通过将输出重定向后对日志进行过滤，去除冲突的日志。或者自己编写脚本，定期从 frpc 的 api 获取代理状态，如果出现冲突则主动 kill 掉 frpc 进程。

@fatedier commented on GitHub (Jul 8, 2021): 一个客户端并非一定只有一个 proxy，所以出现冲突就退出不是很合理。你可以理解客户端的配置是声明式的，只要你配置了，就会不断尝试去将当前状态和配置项匹配。你可以尝试，通过将输出重定向后对日志进行过滤，去除冲突的日志。或者自己编写脚本，定期从 frpc 的 api 获取代理状态，如果出现冲突则主动 kill 掉 frpc 进程。

gitea-mirror commented

2026-05-05 13:15:26 -06:00

Author

Owner

@catchfishday commented on GitHub (Jul 14, 2021):

好的，多谢指导

@catchfishday commented on GitHub (Jul 14, 2021): 好的，多谢指导

gitea-mirror commented

2026-05-05 13:15:27 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 14, 2021):

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 (Aug 14, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.