Score:0

Forwarding https requests to http with Nginx

cn flag
Ray

I'm trying to use Nginx on a Server A (Ubuntu 22.04) to:

  1. Force the client to use https.
  2. Forward requests to a Server B (also Ubuntu 22.04) so that they are http only. It has a Apache2 web server which serves pages from WordPress.

I presume this sounds a bit strange, but Server A and Server B are physically right next to each other. And Server B is behind an company firewall so that none of its ports (80/443) are accessible from the outside. Up until now, I have been unable to set up certificates using Let's Encrypt since Server B has to have a domain name that can be verified from the outside.

Server A is accessible from the outside world (ports 80/443).

And, quite frankly, the web pages that are being served never ask for the user's personal information -- no credit cards, passwords, or any personal information. So, actually, https is perhaps unnecessary. But I do know that some users might have set their web browsers to only use https connections. So, our motivation is to not overly concern visitors to our site who worry when they don't see that padlock next to the address bar.

Anyway, I think Server B's configuration is fine. At least, internal tests seem to be fine, though I will probably do additional tests locally. I'm worried about Server A's Nginx configuration since I'm a bit new to Nginx.

At the moment, part of its configuration is below, where 123.123.123.123 is the IP address of Server B (since it doesn't have a domain name). There are other sites in the configuration file which were set up by my predecessor at work, who was more knowledgeable with Nginx. So, I'm assuming everything he did was right and it's just me adding these two new parts who is wrong.

http {
  server {
    listen 80 ;
    server_name example.com ;

    rewrite ^(.*) https://$server_name$request_uri permanent;
  }

  server {
    listen 443 ssl ;
    server_name  example.com ;
    error_log /var/log/nginx/example-ssl.log ;

    ssl_certificate      /cert/fullchain.pem ;
    ssl_certificate_key  /cert/privkey.pem ;

    location / {
      proxy_redirect off ;
      proxy_pass http://123.123.123.123:80 ;
      proxy_set_header Host $host ;
      proxy_set_header X-Real-IP $remote_addr ;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;
    }
  }
}

The above does not work. Honestly, I've tried many options that I can't remember what it looked like. I think the web pages just failed to load.

A more recent option listened to port 80 and forwarded it directly to http://123.123.123.123:80. This caused a loop. I didn't post that in this question because I think what I have above is probably closer to what it should be.

I guess I'm wondering if what I'm doing makes sense, given my situation where the backend server is behind a firewall (which I cannot lower or control). And if it does make sense, is the above configuration for Nginx correct?

Thank you in advance!

in flag
I no longer use nginx so cannot test this, but I've generally always had `proxy_pass` as the *last* item in the configuration as that ensured the headers and other items were correctly assigned to the request
Richard Smith avatar
us flag
The configuration looks fine assuming that the `server` blocks are in the same `http` block as all of your other `server` blocks. What is the failure mode? Use `nginx -T` (uppercase `T`) to view the entire configuration across all included files and ensure that the two server blocks appear. Edit your question and add a `curl` command used to test the service together with the access log and error log entries that demonstrate the problem.
cn flag
Ray
@matigo Thanks a lot for the advice! I had copied the configuration from somewhere else in the file, written by my predecessor. I've moved `proxy_pass` to the end now. I believe you more than him... Thank you!
cn flag
Ray
@RichardSmith Thanks a lot for taking a look at the configuration and confirming that at least it was fine. I mistakenly thought it wasn't working, but it was. The web page was shown incorrectly, but through an encrypted connection. Turns out the WordPress-based page had a mix of `https` and `http`. And the `http` parts was being blocked by the browser. I guess the theme / plugins I was using had it hardcoded in. After spending the past few days sorting that out, it's now all fine. Thank you for your help!
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.