0

Our documentation server at code.kx.com uses NGINX 1.12.2 under CentOS to serve static HTML. The firewall allows SSH, HTTP, HTTPS only. Our custom search engine runs as a HTTP server on port 5023 on the same machine.

The NGINX config file redirects HTTP to HTTPS. 

server { listen 80 default_server; listen [::]:80 default_server; server_name code.kx.com; return 301 https://$server_name$request_uri; }

It also reverse-proxies search requests by HTTP to the search engine, which returns HTML. 

# Reverse-proxy to kxsearch-v2 service * 2018.12.21 location /v2/search { proxy_pass http://127.0.0.1:5023/q/search; }

The HTTP response appears as from code.kx.com:80, as can be seen by 

curl -i https://code.kx.com/v2/search?query=iasc

Problem Visitors from behind three different corporate proxy servers report seeing the IP address of the search engine exposed. (It is of course the same IP address as code.kx.com.) In two cases their proxy servers deny access to the IP address. In the third, the browser alerts to the switch from HTTPs to HTTP, then again for the switch back to HTTPS, before displaying the results page.

This behaviour is as if the browsers were redirected to the backend server.

The NGINX documentation mentions nothing like this. Question 750605 has a similar configuration, but is trying only for redirection.

Improve this question
5
  • 1
    You're talking to the wrong people. The first place to go is the developers of the custom search engine. Commented Mar 8, 2019 at 21:04
  • That would be me. What should I say? Commented Mar 9, 2019 at 0:26
  • My first thought is that this sounds normal. What do you mean it is exposing the internal IP? You just said the other users see the IP address, which is the same as code.kx.com, and that the response headers say code.kx.com? So, in other words, only normal stuff is exposed. Of course code.kx.com converts to your IP address and vice-versa. The internet doesn’t work without that, which I’m assuming you know. So, try to explain your problem better. Is there something the user is seeing that isn’t public knowledge? Commented Mar 9, 2019 at 6:35
  • Two problems with the above. The immediate problem is the corporate clients who don’t have my server IP address whitelisted. Their networks block the response: e.g. URLs may not specify the host by IP address. Presumably, if my search engine were at a different IP address, they would see that. And the protocol shift is exposed, raising browser alerts. I expect the shift to HTTP (between NGINX and the search engine) to be cloaked by the reverse proxy. Broadly, I seem to be seeing a redirect rather than a reverse proxy. Commented Mar 9, 2019 at 8:04
  • You need to ask yourself why your code is sending out that IP address in the first place. Commented Mar 9, 2019 at 16:51

1 Answer 1

Reset to default
0

This turns out to be a duplicate of Unix/Linux question Nginx reverse proxy redirection.

The key part of the answer is

proxy_set_header Referer $http_referer;

This sets the Referer field sent to my search engine. Evidently the response sent to the browser depends on the headers in the search engine’s response in ways I need to understand better.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.