-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proxy protocol support fo outgoing connections #191
Comments
It doesn't support the PROXY protocol for outgoing connections but that sounds like a good idea. I'll add it to the list. |
I've refactored the listeners and servers in the |
I also would like to see this feature. For now I've tried to implement this myself but since I didn't know a nice way to get to route tags / options inside of the SNI Proxy I wasn't able to make the I am hoping that your version will have an option to set the header on an as-needed basis so a single port can be shared between My very crude implementation can be found here: lukas2511@deaa518 |
Hmm, that looks simple enough to be added as a listener option like read/write timeout. No need to duplicate the entire proxy for that. Let me see whether I can cook something up tomorrow or so. |
I'm wondering whether this is something that needs to be configurable per upstream server, e.g. some upstream servers want PROXY protocol and others don't? @lukas2511 @tkald what's your take on that? The reason I'm asking is that there is currently no support for upstream servers announcing their capabilities. This isn't difficult to add but more work than a global switch. |
@magiconair I would like to have this on a per-route basis, upstream server shouldn't be involved in making this decision, just the consul services. |
@lukas2511 since the route is announced by the upstream server through consul it needs to advertise this somehow. How do you envision this to work? |
@magiconair the project readme has a few examples for other tags:
Maybe something like
Or is this not possible? |
Sorry i think I just misunderstood what you meant with "upstream server", for me that was the upstream webserver, but now I notice that you mean the whole system, so yea, this should come from the upstream server, sorry for the confusion. |
Thank you for 1.5.11 release. It helped me to understand that I actually have a problem described in this issue. I thought Fabio can talk Proxy protocol in any direction. Hope this will be fixed. |
@pashinin Right now I have almost no time to work on this project other than urgent bug fixes and merging contributions. If you need this feature then the best chance is to submit a PR. |
I'd be happy to review/comment on the PR. |
@leprechau FYI: Proxy protocol for outgoing connections implemented on PR #598 |
Tested Fabio with mentioned PR. Works with 2 Exim servers configured for Proxy protocol. |
Then let’s merge |
As I understand, fabio supports incoming proxy protocol connections.
What about outgoing connections?
CLIENT (ip 1.2.3.4) ---> Fabio (ip 5.6.7.8) ---> webserver (ip 9.10.11.12)
For now, webserver sees requests originating from ip 5.6.7.8 not from client ip 1.2.3.4.
I know, there are x-forwarded-for headers...
Since nginx supports incoming proxy protocol connections, would be nice if fabio could provide that output with http and tcp.
The text was updated successfully, but these errors were encountered: