[GH-ISSUE #5273] [Feature Request] Support NewVisitorConn operation in server plugin callbacks

gitea-mirror commented

2026-05-05 14:34:48 -06:00

Owner

Originally created by @YH-Wang000 on GitHub (Apr 1, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5273

Describe the feature request

Description
When using stcpproxies, the remote host may be in sleep mode and require Wake-on-LAN (WOL) to wake up. Currently, accessing it requires two separate steps:

Manually trigger WOL (e.g., via a separate script).
Connect via the frp tunnel.

This breaks the seamless remote access experience. I wish to automate this by using the frp server plugin callback, but the newvisitorconnoperation (which signals a visitor is connecting to an stcp proxy) is not currently exposed in the plugin's opsconfiguration.

Proposal
Please add support for the newvisitorconnoperation to the server plugin system. This would allow configuration like:

[[httpPlugins]]
name = "port-manager"
addr = "127.0.0.1:9001"
path = "/handler"
ops = ["NewVisitorConn"]

Expected Workflow

A visitor attempts to connect to an stcpproxy.
frps triggers the plugin callback (op=newvisitorconn).
The plugin can then:
- Send a WOL packet to the target host.
- Return a response with a delay(e.g., 60 seconds).
frps waits for the delay, allowing the host to boot, then proceeds with the connection.

Benefits

Seamless UX: Merges the wake-up and connect steps into a single, transparent action for the end user.
Generic & Useful: While my use case is WOL, exposing this operation enables other pre-connection logic for stcp(auth, logging, etc.).
Small Change: Aligns with the existing plugin pattern (e.g., newuserconnfor TCP/UDP).

Context
frp version: v0.68.0
Proxy type: stcp(for RDP access)
Current workaround: External service, which is less integrated.

Describe alternatives you've considered

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 @YH-Wang000 on GitHub (Apr 1, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5273 ### Describe the feature request **Description** When using stcpproxies, the remote host may be in sleep mode and require Wake-on-LAN (WOL) to wake up. Currently, accessing it requires two separate steps: 1. Manually trigger WOL (e.g., via a separate script). 2. Connect via the frp tunnel. This breaks the seamless remote access experience. I wish to automate this by using the frp server plugin callback, but the newvisitorconnoperation (which signals a visitor is connecting to an stcp proxy) is not currently exposed in the plugin's opsconfiguration. **Proposal** Please add support for the newvisitorconnoperation to the server plugin system. This would allow configuration like: ```toml [[httpPlugins]] name = "port-manager" addr = "127.0.0.1:9001" path = "/handler" ops = ["NewVisitorConn"] ``` **Expected Workflow** 1. A visitor attempts to connect to an stcpproxy. 2. frps triggers the plugin callback (op=newvisitorconn). 3. The plugin can then: - Send a WOL packet to the target host. - Return a response with a delay(e.g., 60 seconds). 4. frps waits for the delay, allowing the host to boot, then proceeds with the connection. **Benefits** 1. Seamless UX: Merges the wake-up and connect steps into a single, transparent action for the end user. 2. Generic & Useful: While my use case is WOL, exposing this operation enables other pre-connection logic for stcp(auth, logging, etc.). 3. Small Change: Aligns with the existing plugin pattern (e.g., newuserconnfor TCP/UDP). **Context** frp version: v0.68.0 Proxy type: stcp(for RDP access) Current workaround: External service, which is less integrated. ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [x] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:34:48 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:34:53 -06:00

Author

Owner

@fatedier commented on GitHub (Apr 1, 2026):

For STCP proxies, visitor connections already go through the NewUserConn plugin hook once the proxy is registered, so you can already run pre-connection logic at that point.

However, the core problem in your WOL scenario is that the backend host is asleep, meaning frpc isn't running and the STCP proxy isn't registered on frps at all. To support this, frps would need to hold visitor connections, wait for an unregistered proxy to appear, and retry — which adds significant complexity to the server and is not something we want to take on. The server should focus on routing and forwarding, not orchestrating backend availability.

This kind of orchestration is better handled outside of frps.

@fatedier commented on GitHub (Apr 1, 2026): For STCP proxies, visitor connections already go through the `NewUserConn` plugin hook once the proxy is registered, so you can already run pre-connection logic at that point. However, the core problem in your WOL scenario is that the backend host is asleep, meaning frpc isn't running and the STCP proxy isn't registered on frps at all. To support this, frps would need to hold visitor connections, wait for an unregistered proxy to appear, and retry — which adds significant complexity to the server and is not something we want to take on. The server should focus on routing and forwarding, not orchestrating backend availability. This kind of orchestration is better handled outside of frps.

gitea-mirror commented

2026-05-05 14:34:53 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 16, 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 (Apr 16, 2026): 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:51:07 -06:00

[PR #4074] [MERGED] update release notes #4911

gitea-mirror referenced this issue

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

[PR #4092] [MERGED] bump v0.56.0 #4918