0

I have a Debian 6.0 webserver correctly running with the following setup:

Nginx as front-server listening on the WAN facing interface port 80
    Serving the domain HTTP mydomainame dot org (via reverse proxy to Apache)
    Directly serving and caching static files

Apache as backend-server listening on localhost port 8080 and WAN facing interface port 443
    Serving the domain HTTP mydomainame dot org (behind Nginx reverse proxy)
    Directly serving SSL for HTTPS mydomainame dot org (port 443)

I have to deal with another server that I don't manage which is supposed to serve only HTTPS mydomainame dot org/subdir.

So this external server should be listening on (WAN) port 443 and serving the subdirectory /subdir under the same domain name (mydomainame dot org).

Note that the DNS records for mydomainame dot org point to my Debian server.

The very first thing I tried was to get my Nginx setup so that it would reverse proxy any /subdir request to the external server IP:

  location ^~ /subdir {
    proxy_pass https://000.000.00.000;
    include /etc/nginx/proxy_subdir.conf;
    error_log /var/log/nginx/mydomainame_subdir.errors.log;
    access_log /var/log/nginx/mydomainame_subdir.access.log;
    expires off;
  }

Then set the headers like so:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header Host "mydomainame dot org";

What happens in this case is that the external server bounces back the request with a 301 and redirects to HTTPS mydomainame dot org/subdir which the DNS records basically resolve back to my Debian Apache server listening on port 443.

I think this happens because the application running on the external server (Magento) rewrites the base_url to HTTPS mydomainame dot org/subdir, but I am not fully sure of this fact.

So a browser ends up hitting my server but Apache is not configured to serve /subdir so of course I get a 404.

Should I setup my Apache listening on port 443 to yet again reverse proxy back to the external server?

It sounds like a good way to create a redirect loop so I am a bit sceptic.

I think the problem is actually on the external server but I am not exactly sure of what to suggest to the maintainers of that host.

They too use Nginx, but serving SSL directly on port 443.

Thanks for any suggestion on this mess!

2 Answers 2

0

I'd fire up tcpdump port 443 on the Apache host and see who is sending the 404, or tweak your 404 message to include some nickname to identify which box is throwing the 404. Also, have you proven out the final destination https://somehost.org/subdir is even functional at this point?

3
  • The 404 is definitely coming from my Apache host because of the request bouncing back from the external server. My Apache machine is not setup to handle /subdir. Regarding the destination, to be honest I am not sure - they are telling me that the problem is on my config but I don't see where the glitch might be in what I've posted above.
    – bashintosh
    Aug 2, 2014 at 5:20
  • Any reason you can't have them use a different hostname as the target, and avoid this altogether via DNS? Might be worth asking.
    – Bee Kay
    Aug 3, 2014 at 5:13
  • Good question - the application running on the external server (Magento) should live under /subdir (same domain as the Debian server). Using a different domain (or subdomain) works great but the final URL used by the browser won't match the original site (running on Debian). I am exploring workarounds using URL rewrites but the real issue is that the application (PHP)rewrites its base URL automatically so if I use a different domain name for the external server I also have to change the app base URL which would still result in a redirect to something that is not mydomainame dot org/subdir.
    – bashintosh
    Aug 5, 2014 at 5:07
0

Perhaps it is time to cheat with port and IP redirection.

Configure https at mydomainname dot org:8443/subdir as the reply from NGINX. Then add rinetd to whichever box would receive this reply, blindly redirecting port 8443 traffic over to port 443 on the unmanaged box. (Remember to add firewall rules to allow 8443 to be received on Apache/NGINX system(s).)

It should perform the following:

incoming https at mydomainname dot org:443/subdir > 
NGINX rewrite to https at mydomainname dot org:8443/subdir >
incoming https at mydomainname do org:8443/subdir >
NGINX/APACHE rinetd forwards directly to https at notmyserver dot org:443/subdir

Could this work for you?

Also, I would definitely prove their end will accept the requests, because it may already be correct on your side, but not accepted on their side. Easiest way? Use their IP address in the url call and see if you get a 404 or the site.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .