[GH-ISSUE #4705] [Feature Request] Support Incoming PROXY Protocol in frpc #3714

Open
opened 2026-05-05 14:22:58 -06:00 by gitea-mirror · 2 comments
Owner

Originally created by @MahdiAkrami01 on GitHub (Mar 11, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4705

Describe the feature request

Hi
I’m using frpc behind HAProxy, which sends PROXY protocol v2 headers to pass client info. Currently, frpc doesn’t seem to support accepting incoming PROXY headers on its listening ports.
This causes connection failures when HAProxy uses send-proxy-v2.

Could you please consider adding support for frpc to accept incoming PROXY protocol (v1/v2)? Something like an acceptProxyProtocol = "v2" option in [[proxies]] would be amazing. It’d help log client IPs and work better with upstream proxies like HAProxy.

Thanks for your great work - happy to help test if needed

Flow

Client ---> HAProxy ---(Add PROXY v2)---> frpc ---(Log then remove PROXY v2)---> Local app

haproxy

listen chatWS
    mode http
    balance leastconn
    bind *:443 shards by-thread ssl crt key.pem

    server s01  :::8443 send-proxy-v2

frpc

proxies
name = "server-s01"
type = "tcp"
localIP = "::"
localPort = 8443
remotePort = 8443
transport.proxyProtocolVersion = ""
acceptProxyProtocol = "v2" <------ Not currently supported

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 @MahdiAkrami01 on GitHub (Mar 11, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4705 ### Describe the feature request Hi I’m using `frpc` behind `HAProxy`, which sends `PROXY protocol v2` headers to pass client info. Currently, `frpc` doesn’t seem to support accepting incoming `PROXY` headers on its listening ports. This causes connection failures when `HAProxy` uses `send-proxy-v2`. Could you please consider adding support for `frpc` to accept incoming `PROXY` protocol (v1/v2)? Something like an `acceptProxyProtocol = "v2"` option in `[[proxies]]` would be amazing. It’d help log client IPs and work better with upstream proxies like `HAProxy`. Thanks for your great work - happy to help test if needed ## Flow **Client ---> HAProxy ---(Add PROXY v2)---> frpc ---(Log then remove PROXY v2)---> Local app** ## haproxy ``` listen chatWS mode http balance leastconn bind *:443 shards by-thread ssl crt key.pem server s01 :::8443 send-proxy-v2 ``` ## frpc [[proxies]] name = "server-s01" type = "tcp" localIP = "::" localPort = 8443 remotePort = 8443 transport.proxyProtocolVersion = "" acceptProxyProtocol = "v2" <------ Not currently supported ### Describe alternatives you've considered _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 added the
proposal
label 2026-05-05 14:22:58 -06:00
Author
Owner

@fatedier commented on GitHub (Mar 12, 2025):

Why don't you just pass the proxy protocol information to your local app?

<!-- gh-comment-id:2716284169 --> @fatedier commented on GitHub (Mar 12, 2025): Why don't you just pass the proxy protocol information to your local app?
Author
Owner

@MahdiAkrami01 commented on GitHub (Mar 12, 2025):

Why don't you just pass the proxy protocol information to your local app?

I’m using multiple apps, and not all of them support proxy protocol information. It’d be great if there could be a workaround or additional flexibility for cases like mine where app support varies.

<!-- gh-comment-id:2716968818 --> @MahdiAkrami01 commented on GitHub (Mar 12, 2025): > Why don't you just pass the proxy protocol information to your local app? I’m using multiple apps, and not all of them support proxy protocol information. It’d be great if there could be a workaround or additional flexibility for cases like mine where app support varies.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#3714
No description provided.