Hello,
We are using nginx on a server as a reverse proxy and it works fine
serving multiple websites.
Now I am trying to reverse proxy another one, a WP website, in the same
way, but it won't render correctly.
I can only see the main page areas and only some text at some places,
but most content, including images, is missing.
What may be wrong?
I have checked error logs but I don't see anything logged.
Any suggestions will be most appreciated.
In the config below, the original site (http://example.private.noa.gr)
works without issues (it is rendered properly), but the proxied one
(https://example.noa.gr) does not.
Here is the config:
===========================================================
server {
listen 80;
listen [::]:80;
server_name example.noa.gr;
return 301 https://example.noa.gr/$request_uri;
access_log /var/log/example_http_access_log main;
error_log /var/log/example_http_error_log warn;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.noa.gr;
allow 127.0.0.1;
allow ::1;
allow 10.10.0.0/16;
deny all;
ssl_certificate /etc/pki/tls/certs/star_noa_gr_cert-current.crt;
ssl_certificate_key /etc/pki/tls/private/star_noa_gr-1243437.key;
access_log /var/log/example_https_access_log main;
error_log /var/log/example_https_error_log warn;
client_max_body_size 50M;
location / {
proxy_pass http://example.private.noa.gr:80/;
proxy_set_header Host example.private.noa.gr;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Server $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_buffer_size 16k;
proxy_max_temp_file_size 2048m;
proxy_buffers 8 16k;
}
}
===========================================================
(Note: the buffer directives were added to avoid the "an upstream
response is buffered to a temporary file" error.)
Thanks in advance.
Best regards,
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4466 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20241015/ff82e06a/attachment.bin>
Hi Nick,
have you tried to remove the trailing slash from the upstream url?
Turning: "proxy_pass http://example.private.noa.gr:80/;"
info: "proxy_pass http://example.private.noa.gr:80;"
If this resloves your issue, you can find the details in the docs here:
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
--
Best regards
Kevin Weis
Pronouns: he / him
https://compilenix.org
On 15/10/2024 5:11 μ.μ., Kevin Weis via nginx wrote:
> have you tried to remove the trailing slash from the upstream url?
Hi Kevin,
Thanks for the hint.
I tried that but no, removing the trailing slash did not change anything.
Any other hints will be welcome!
Thanks again,
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4466 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20241016/0f6e0ab7/attachment.bin>
On 16/10/2024 12:19 π.μ., Nikolaos Milas via nginx wrote:
> ...
> I tried that but no, removing the trailing slash did not change anything.
> ...
I found that the problem is that, as the proxied page is rendered over
SSL, browsers are auto-blocking parts of the page as non-secure.
This is due, I guess, to the fact that multiple page items are probably
hardcoded as http rather than as https links or as absolute rather than
as relative paths (images etc).
I'll have to ask the developer to check the app throughout.
Sorry for the fuss.
All the best,
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4466 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20241016/5811d969/attachment-0001.bin>
You could consider adding a CSP header to cause clients to automatically
fetch those resources over HTTPS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
On Wed, 16 Oct 2024 at 00:06, Nikolaos Milas via nginx <nginx at nginx.org>
wrote:
> On 16/10/2024 12:19 π.μ., Nikolaos Milas via nginx wrote:
>
> > ...
> > I tried that but no, removing the trailing slash did not change anything.
> > ...
>
> I found that the problem is that, as the proxied page is rendered over
> SSL, browsers are auto-blocking parts of the page as non-secure.
>
> This is due, I guess, to the fact that multiple page items are probably
> hardcoded as http rather than as https links or as absolute rather than
> as relative paths (images etc).
>
> I'll have to ask the developer to check the app throughout.
>
> Sorry for the fuss.
>
> All the best,
> Nick
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20241016/d1b3a542/attachment.htm>