Score:0

Issue with Web Server running PHP thru Reverse Proxy

cn flag

I'm using an NGINX reverse proxy, with wild card certs installed on the reverse proxy. Routing the NGINX reverse proxy traffic to standard web servers that are running Apache2 and NGINX Web services is working great.

However, routing to a server that uses PHP code and Apache2 does not show the page correctly. I believe the PHP code or header information is not passing through the reverse proxy correctly.

EVERYTHING LOOKS GREAT when I go directly to the PHP Web server using HTTP and its internal IP address.

Web PAGE layout and graphics look entirely different, The graphical layout is missing when routing to my PHP server through the reverse proxy. The NGINX reverse_proxy configuration is as follows:

   listen 80;
   server_name itop.My_Domain_Name.org;
   return 301 https://$host$request_uri;
  }
  server {
   listen 443 ssl;
   server_name itop.surfingjoe.org;
   ssl_certificate /etc/letsencrypt/live/My_Domain_Name.org/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/liveMy_Domain_Name.org/privkey.pem;

      location / {
          proxy_pass http://192.168.1.4;
          include proxy_params;
      }
  }```
I'm sure there is a change I need to make to the NGINX configuration in order to make it work, but I'm a newbie to using NGINX reverse proxy and sure would like some help, please.

HBruijn avatar
in flag
Note that by default and by design ***a reverse proxy does not change HTML and other content*** it fetches from the back-end server. For example an absolute reference to `link rel="stylesheet" href="http://192.168.1.4/assets/style.css"` doesn't get translated to `href="https://itop.surfingjoe.org/assets/style.css"` and will result in a missing style-sheet and different design. - When you *"I believe the PHP code or header information is not passing through the reverse proxy correctly."* don't just rely on your guts, check, run a diff and see if that indeed case.
HBruijn avatar
in flag
Does this answer your question? [How to handle relative urls correctly with a nginx reverse proxy](https://serverfault.com/questions/932628/how-to-handle-relative-urls-correctly-with-a-nginx-reverse-proxy)
djdomi avatar
za flag
you may have overcome by a nginx default action: caching. I would try with a negative value for testing
Score:0
cn flag

HBrujin did manage to answer the question with the statement, "Don't just rely on your guts, check". So I did a check.

Using the Firefox browser, I used "Inspect" on the failed web page and found the problem. I found the trailing slash was missing between the domain name and a sub-directory.

When configuring the application server (ITOP, an ITSM solution), during the configuration of the application via a browser, I input the application's domain address. For example, https://example.com/itop, but I should have placed the application's address as https://example.com/itop/. The difference is that the trailing slash ("/") was missing in my configuration of the application.

I have no clue why addressing via IP address directly worked but via reverse proxy fails. When HBrujin asked me to "check" and not trust my gut, I used Firefox inspect mode and found the problem.

So Thank You

PS. Turns out the problem was not my configuration of NGINX reverse proxy after all.

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.