[GH-ISSUE #3591] [Feature Request] Restore Original IP address using iptables/masquerade

gitea-mirror commented

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

Owner

Copy link

Originally created by @xorweak on GitHub (Aug 29, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3591

Describe the feature request

Hey there,

So, I'm using this reverse proxy to kinda "mask" the real IP address of a game server, and it's working like a charm. But, there's this one little hiccup: the players' IP addresses show up as "127.0.0.1" instead of their actual IPs.

Any idea what might be causing this glitch? Is there a way to get back the players' original IP addresses? I used to pull this off before with a VPN Server + iptables combo, but man, the connection was terrible. Tons of lag inside the server, which totally killed the gaming experience.

Not sure if this is tied directly to the reverse proxy setup. If there's a different approach to sort this out without messing with the proxy, could someone point me in the right direction?

Thanks a ton.

Describe alternatives you've considered

OpenVPN + iptables
GRE Tunnel

Affected area

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

Originally created by @xorweak on GitHub (Aug 29, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3591 ### Describe the feature request Hey there, So, I'm using this reverse proxy to kinda "mask" the real IP address of a game server, and it's working like a charm. But, there's this one little hiccup: the players' IP addresses show up as "127.0.0.1" instead of their actual IPs. Any idea what might be causing this glitch? Is there a way to get back the players' original IP addresses? I used to pull this off before with a VPN Server + iptables combo, but man, the connection was terrible. Tons of lag inside the server, which totally killed the gaming experience. Not sure if this is tied directly to the reverse proxy setup. If there's a different approach to sort this out without messing with the proxy, could someone point me in the right direction? Thanks a ton. ### Describe alternatives you've considered 1. OpenVPN + iptables 2. GRE Tunnel ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [X] Security - [X] User Experience - [ ] Test and Release - [X] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [X] Others

gitea-mirror

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

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

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

Author

Owner

Copy link

@fatedier commented on GitHub (Aug 30, 2023):

If your service is using TCP protocol, you can refer to the documentation at https://github.com/fatedier/frp#proxy-protocol to enable Proxy Protocol and obtain the real IP.

If it is UDP, currently it is not supported, but there is a possibility of support in the future.

iptables releated feature is not used.

@fatedier commented on GitHub (Aug 30, 2023): If your service is using TCP protocol, you can refer to the documentation at https://github.com/fatedier/frp#proxy-protocol to enable Proxy Protocol and obtain the real IP. If it is UDP, currently it is not supported, but there is a possibility of support in the future. `iptables` releated feature is not used.

gitea-mirror commented

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

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Sep 30, 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 30, 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:46:01 -06:00

[PR #2867] [MERGED] add release note #4644

gitea-mirror referenced this issue

2026-05-05 14:46:02 -06:00

[PR #2869] [MERGED] bump version to v0.41.0 #4646

No Branch/Tag specified