[GH-ISSUE #4885] XTCP Health Check

gitea-mirror commented

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

Owner

Originally created by @MahdiAkrami01 on GitHub (Jul 18, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4885

Bug Description

The issue is that when I use standard TCP, I can detect if the tunnel is down by checking a TCP ping. However, when using XTCP, the ports continue listening even if the tunnel is down, making it difficult to verify whether the tunnel is operational. I am using HAProxy with a simple TCP check. I have three tunnels:

backend nginx
    mode tcp
    option tcp-check
    server s01 10.0.0.2:8080 # wg
    server s02 ::1:8080 backup # tcp
    server s03 ::1:8081 backup # xtcp

The xtcp tunnel is always considered operational, even when the tunnel is down.
I know that I can set up complex health checks using HAProxy agents, but I think it's better to try fixing this in a simpler way.

frpc Version

0.63.0

frps Version

0.63.0

System Architecture

linux/amd64

Configurations

Logs

No response

Steps to reproduce

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 @MahdiAkrami01 on GitHub (Jul 18, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4885 ### Bug Description The issue is that when I use standard TCP, I can detect if the tunnel is down by checking a TCP ping. However, when using XTCP, the ports continue listening even if the tunnel is down, making it difficult to verify whether the tunnel is operational. I am using HAProxy with a simple TCP check. I have three tunnels: ``` backend nginx mode tcp option tcp-check server s01 10.0.0.2:8080 # wg server s02 ::1:8080 backup # tcp server s03 ::1:8081 backup # xtcp ``` The xtcp tunnel is always considered operational, even when the tunnel is down. I know that I can set up complex health checks using HAProxy agents, but I think it's better to try fixing this in a simpler way. ### frpc Version 0.63.0 ### frps Version 0.63.0 ### System Architecture linux/amd64 ### Configurations . ### Logs _No response_ ### Steps to reproduce _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [x] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:27:54 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 21, 2025):

but I think it's better to try fixing this in a simpler way

What do you think would be the appropriate way to handle this?

@fatedier commented on GitHub (Jul 21, 2025): > but I think it's better to try fixing this in a simpler way What do you think would be the appropriate way to handle this?

gitea-mirror commented

2026-05-05 14:27:54 -06:00

Author

Owner

@MahdiAkrami01 commented on GitHub (Jul 21, 2025):

It must start listening only after the P2P tunnel is successfully connected
It should also stop listening if the tunnel is disconnected
Is it possible to make this happen in XTCP mode?

@MahdiAkrami01 commented on GitHub (Jul 21, 2025): It must start listening only after the P2P tunnel is successfully connected It should also stop listening if the tunnel is disconnected Is it possible to make this happen in XTCP mode?

gitea-mirror commented

2026-05-05 14:27:55 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 21, 2025):

Tunnel establishment is generally delayed and only created when there is a new connection now.

@fatedier commented on GitHub (Jul 21, 2025): Tunnel establishment is generally delayed and only created when there is a new connection now.

gitea-mirror commented

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

Author

Owner

@MahdiAkrami01 commented on GitHub (Jul 21, 2025):

Okay, so what about this:
Can you forward the TCP ping through the tunnel?
By doing that, when the tunnel is not established, the TCP ping will fail, and the health check will work correctly.
Because right now, I think FRPC is responding to the TCP ping locally instead of routing it through the tunnel.
In the image, the 74 ms is for the WireGuard tunnel, and the others are for XTCP.

@MahdiAkrami01 commented on GitHub (Jul 21, 2025): Okay, so what about this: Can you forward the TCP ping through the tunnel? By doing that, when the tunnel is not established, the TCP ping will fail, and the health check will work correctly. Because right now, I think FRPC is responding to the TCP ping locally instead of routing it through the tunnel. In the image, the 74 ms is for the WireGuard tunnel, and the others are for XTCP. <img width="291" height="156" alt="Image" src="https://github.com/user-attachments/assets/b3fd30cf-dbc9-4306-99a2-41161aea93e9" />

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Jul 21, 2025):

xtcp is L4 proxy like nginx and haproxy. It works differently from WireGuard.

@fatedier commented on GitHub (Jul 21, 2025): xtcp is L4 proxy like nginx and haproxy. It works differently from WireGuard.

gitea-mirror commented

2026-05-05 14:27:57 -06:00

Author

Owner

@MahdiAkrami01 commented on GitHub (Jul 21, 2025):

so the only way to bypass this is to use VirtualNet right?
is VirtualNet support xtcp mode?

@MahdiAkrami01 commented on GitHub (Jul 21, 2025): so the only way to bypass this is to use VirtualNet right? is VirtualNet support xtcp mode?

gitea-mirror commented

2026-05-05 14:27:58 -06:00

Author

Owner

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