Client A -> Nginx Server B -> Back-End Server C
Back-End Server C needs real IP of Client A.
How to do to solve this?
Can I just config Nginx Server B to solve it?
I find some way on nginx.com.
See:
9:43 Passing the Client’s IP Address to the Backend
IP Transparency and Direct Server Return with NGINX
Proxy Protocol
Related
I need to setup a reverse proxy server which would distribute traffic to the backend servers based on the incoming HOST header.
I opted for HAproxy for this but after setting up everything I realized that HAproxy reads the configuration just once when the service starts and continues to use the backend IP address unless it has been reloaded/restarted.
This is an issue for me since in my case if the backend server reboots it will have a different IP address and I dont have control on which IP address it gets.
I am thinking of moving to nginx server but before I go through all the setup I would like to know if we have the same issue with Nginx or not?
Meaning: If in the configuration file I have specific the name of backend server and if the related IP address changes, will Nginx refresh its dns cache to identify the new IP address?
(When the backend server changes IP, it is automatically updated in the hosts file of proxy server)
Yes, nginx will do the job. See 'resolve' option here:
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server
Let us suppose that on my machine it is configured a proxy server.
Let now suppose that I want to visit www.sitename.com, what happens?
In particular, I send an HTTP GET www.sitename.com request to the proxy server and it queries his own dns or, on the contrary, I query my dns and then I send an HTTP GET IPfromDNS to the proxy server?
With a HTTP proxy you send the URL to the proxy and the DNS lookup is done by the proxy. With a SOCKS4 proxy the client need to do the DNS lookup itself since this kind of proxy can only forward to IP addresses. SOCKS5 instead allows you again to forward by name so that the DNS lookup is done by the proxy.
I am not sure how to formulate my question but here we go:
I have 2 servers, one is the nginx reverse proxy and one is the app server.
In my app server, I am developing a simple http client using jerseyclient that will send a request to another server. I can do this now but the traffic goes from the app server and directly to the destination. Is it possible to it from the app server, passes through the reverse proxy server and goes to the destination?
And, is this design ok or is it an abomination?
nginx reverse proxy works only for requests outside your network.
To configure your system works as you described you have to configure firewall NAT or caching HTTP proxy like squid etc.
If you have no reasons why your servers should look as single computer - your configuration is OK.
So, a Client connects to Server A, which then creates an iframe pointed at Server B. The Client submits a request through the iframe to Server B. Does Server B see the request as coming from the Client or from Server A?
Application: I have two services running on one machine, let's say one on port 443 and one on port 9090. Port 9090 is closed at the firewall, but it can be accessed from other services on the host machine. If I host a page on 443 with an iframe directed at port 9090, will that service see that request as coming from the host machine and send the data, or from the external client and drop the connection?
Server B will see the request coming from the client browser not from server A.
Generally Iframes are requesting its URL from the client browser.
Regarding a proxy built using Netty. Note: Server C has a custom protocol. (not http)
Given a client 'A', Netty proxy 'B' and server 'C'
Will the server C be able to determine the IP of the Client A on an incoming connection?
Or will the client IP always appear to the Server to be B's IP?
Many thanks.
The server will not be able to see the client ipaddress. It will always only see the ipaddress if the proxy. One way to handle this is to encode the "original ipaddress" in the protocol so it can be extracted later at the server. For example in http you could use a header for this kind of thing. Same goes for smtp etc.