[GH-ISSUE #3009] udp gaming server access, minimal latency [Feature Request]

gitea-mirror commented

2026-05-05 13:32:52 -06:00

Owner

Copy link

Originally created by @siliconhippy on GitHub (Jul 10, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3009

Describe the feature request

A. Is it possible to use frp to access a udp ( e.g., CSGO) gaming server behind NAT from the Internet, via a single URL that can be used by all clients logging in?

Is kcp udp protocol the answer?
Any use case example?

B. Latency is a big problem with gaming, especially if the public server is geographically distant.

Is there a way for the client gamers to access the behind NAT gaming server directly after connection is initially established by public server?

Describe alternatives you've considered

Boringproxy.io is very easy to use and includes auto SSL cert+ reverse proxy. You get a URL that can be shared by all users (clients.)
But currently it is TCP only. Author is considering an extension to QUIC.
Wireguard is UDP, but most GUI implementations are not free. Latency will be another problem with a distant public server.

Only frp looks a comprehensive http/s, udp, TCP maybe QUIC solution that might have direct user traffic for low latency!

Affected area

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

Originally created by @siliconhippy on GitHub (Jul 10, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/3009 ### Describe the feature request A. Is it possible to use frp to access a udp ( e.g., CSGO) gaming server behind NAT from the Internet, via a single URL that can be used by all clients logging in? Is kcp udp protocol the answer? Any use case example? B. Latency is a big problem with gaming, especially if the public server is geographically distant. Is there a way for the client gamers to access the behind NAT gaming server directly after connection is initially established by public server? ### Describe alternatives you've considered 1. Boringproxy.io is very easy to use and includes auto SSL cert+ reverse proxy. You get a URL that can be shared by all users (clients.) But currently it is TCP only. Author is considering an extension to QUIC. 2. Wireguard is UDP, but most GUI implementations are not free. Latency will be another problem with a distant public server. Only frp looks a comprehensive http/s, udp, TCP maybe QUIC solution that might have direct user traffic for low latency! ### Affected area - [ ] Docs - [X] Installation - [X] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [X] Client Plugin - [X] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:32:52 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:32:56 -06:00

Author

Owner

Copy link

@Becods commented on GitHub (Jul 11, 2022):

You may need XTCP.

But as far as I know, CSGO can't be forwarded well.

If this only serves you and your friends, consider using zerotier to set up a virtual LAN.

@Becods commented on GitHub (Jul 11, 2022): You may need [XTCP](https://github.com/fatedier/frp#expose-your-service-privately). But as far as I know, CSGO can't be forwarded well. If this only serves you and your friends, consider using zerotier to set up a virtual LAN.

gitea-mirror commented

2026-05-05 13:32:56 -06:00

Author

Owner

Copy link

@siliconhippy commented on GitHub (Jul 11, 2022):

Ok thanks!
Xtcp might be the answer... 🤔

@siliconhippy commented on GitHub (Jul 11, 2022): Ok thanks! Xtcp might be the answer... 🤔

gitea-mirror commented

2026-05-05 13:32:57 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Aug 11, 2022):

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

No Branch/Tag specified