My nginx version is 1.4.6:
root#jung-digital:~# nginx -v
nginx version: nginx/1.4.6 (Ubuntu)
I've set up a reverse proxy to a server with version 1.8.0 on it, as confirmed by hitting an invalid path on that server.
However, my reverse proxy is showing an HTML page when attempting to use the reverse proxy saying:
404 Not Found
nginx/1.4.1 (Ubuntu)
What in the world is going on? Neither my reverse proxy server nor the target server for the proxy are using nginx 1.4.1.
For those curious, here are the relevant sections from my nginx.conf:
upstream ireport_dyndns {
server ireport.somedomain.org;
}
...
server {
listen 80;
server_name ireport.somedomain2.com;
access_log /var/log/nginx/ireport.access.log;
root /var/www/ireport.somedomain2.com/dist;
index index.html index.htm;
location /api/ {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'POST,GET,OPTIONS';
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-proxy true;
proxy_pass http://ireport_dyndns/api/;
proxy_ssl_session_reuse off;
proxy_set_header Host $http_host;
proxy_redirect off;
}
}
Discovered that this must be a bug in nginx. The proxied server had a configuration change that was checking the HOST header and my proxy_pass settings were sending the wrong HOST and therefore the proxied server was returning a 404.
The response from the proxied server specifies NGINX 1.8.0 in the headers but 1.4.1 in the body.
Bug in nginx.
Related
I have a NUXT js application on Ubuntu 20.04 Server. I used Nginx to serve my nuxt application as follow:
server {
client_max_body_size 300M;
root /var/www/app/dist;
server_name example.com;
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
My NUXT application works with npm on port 8080 and Nginx reverse proxy, passes user requests to localhost:8080 and everything is working fine.
Now I want to access the js service worker file (named: p-sw.js). but when I try to access it via my website address, (https://example.com/p-sw.js) due to Nginx reverse proxy it returns 404. This file is in the dist folder (see Nginx configuration).
Anybody can explain to me how to set Nginx reverse proxy to works fine as before alongside load service worker file when I enter service worker address (https://example.com/p-sw.js) in browser?
Finally, I solved it!
the Nginx config must look like this:
upstream backend {
server localhost:3000;
}
server {
server_name example.com;
client_max_body_size 300M;
root /var/www/app/dist;
location /p-sw.js {
try_files $uri #backend;
add_header 'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
expires off;
proxy_no_cache 1;
}
location #backend {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
In this configuration, I solved the issue by defining the location /p-sw.js for my service worker file, and for Nuxt routes, I used the same proxy pass!
We are using NGINX on our cPanel server to reverse proxy ZKTeco ZKBioSecurity servers. Due to compatibility with some of their devices not supporting HTTPS, all our servers use HTTP, but, of course, all sessions to our NGINX server is secured with HTTPS and a Sectigo certificate provided by cPanel’s AutoSSL.
Here’s the problem: it seems that the ZKBioSecurity servers are detecting that the client is using HTTPS to connect to them through NGINX, and because of this, give the following prompt each time you want to log in, advising you to download and install the ISSOnline driver and certificate. The certificate, however, is issued to the ZKBioSecurity server for 127.0.0.1, so of course this is rather pointless as we are connecting to the NGINX server using a FQDN. This does not happen if we use HTTP:
So my question: is there something in the request (the HTTP header perhaps?) that NGINX forwards to the upstream server that contains the protocol (HTTPS) the client used to connect to the server? Because this somehow seems to be the case.
Here’s our NGINX config for ZKBioSecurity servers:
location /.well-known {
root /home/novacloud/public_html/subdomain/.well-known;
allow all;
try_files $uri = 404;
}
location / {
if ($scheme = http) {
return 301 https://$host$request_uri;
}
proxy_pass http://192.168.0.1:8080;
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
}
The server_name directive is, of course, managed by cPanel. The above is an example of the include files we use in the main cPanel NGINX configuration file. I thought it was the proxy_set_header X-Forwarded-Proto $scheme, but even if I remove this, I still get the Driver Detection Exception prompt.
Here’s a Pastebin of a cURL of the ZKBioSecurity server from our cPanel/NGINX server
I'm trying to use a proxy pass with nginx to a Kibana pod using a basic auth.
Worked for testing (it's another k8s cluster, but pretty similar, using same namespace, kube-dns, env inside the pods matches and they see each other)
Context: I deploy this via helm at k8s in AWS, the nginx has a Kubernetes LB service type (which basically it's an ELB at AWS with its cname at route53).
If I point nginx pod to kibana-app.kube-system.svc.cluster.local:5601 I see the request at kibana pod from nginx, but returning 404 while trying to go to server.basePath: /api/v1/proxy/namespaces/kube-system/services/kibana-app/
I can access kibana-app pod by getting the url from "kubectl cluster-info" and then checking the logs, the request goes like this:
"method":"get","statusCode":200,"req":{"url":"/app/kibana"
"x-forwarded-uri":"/api/v1/proxy/namespaces/kube-system/services/kibana-logging/app/kibana
Can't find what's going wrong while trying to reach Kibana path from nginx (after doing a basic auth)
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/host.access.log;
location / {
auth_basic "simple auth";
auth_basic_user_file /var/kibana_config/htpasswd;
try_files KIBANA #kibana-app;
}
location #kibanaapp {
return 301 http://kiban-app-url-from-route53/server.basePath;
}
location /api {
proxy_pass https://api.awszone.mydomain/api;
proxy_set_header Authorization "Basic ";
}
}
Also tried to move the proxy_pass statement, removing the return and just doing a proxy_pass from where kibana's pod is listening but either doesn't work, the request never gets to the pod or when the request gets to kibana-app pod, it returns a 404.
Any thoughts?
Thanks!
Update :
I'm almost there, now I can see the "kibana is loading screen" but never finish loading the bundles, json and stuff, nginx pod log:
GET /api/v1/proxy/namespaces/kube-system/services/kibana-logging/bundles/commons.style.css
same request at kibana pod returning 404:
"statusCode":404,"req":{"url":"/app/kibana/v1/proxy/namespaces/kube-system/services/kibana-logging/bundles/commons.bundle.js?v=10146","method":"get","headers":{"host":"kibana.app.env.com","referer":"http://kibana.app.env.com/api "referer":"http://kibana.app.env.com/api"},"res":{"statusCode":404,"responseTime":2,"contentLength":9},"message":"GET /app/kibana/v1/proxy/namespaces/kube-system/services/kibana-logging/bundles/commons.bundle.js?v=10146
my nginx conf:
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/host.access.log;
location / {
auth_basic "simple auth";
auth_basic_user_file /var/kibana_config/htpasswd;
try_files KIBANA #kibana-app;
}
location #kibana-app {
return 301 kibana.app.env.com/server.basePath;
}
location /api {
proxy_pass http://kibana-logging.kube-system.svc.cluster.local:5601;
proxy_set_header HOST $host;
proxy_set_header Referer $http_referer;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Authorization "simple auth ";
}
}
"kibana.app.env.com" it's just the FQDN that kubernetes creates at route53 as a CNAME to an ELB which hits the nodes from where nginx/kibana pods are. That's the url I use at the browser and it should reach nginx, ask me for basic authorization and then take me to kibana pod with server.basePath: /api/v1/proxy/namespaces/kube-system/services/kibana-logging Please, ask me something if I'm not being clear, sorry that I can't just copy/paste everything.
Not sure how this is working on the other cluster. So the base path that you mentioned: /api/v1/proxy/namespaces/kube-system/services/kibana-app/ seems like a kube-apiserver base path, and that's the path that a proxy setup using kubectl proxy would do to talk to your applications and services in the cluster.
If you really want to talk from nginx to Kibana inside the cluster you would have to add the kibana-app.kube-system.svc.cluster.local:5601 endpoint to your nginx backend.
Finally, it's working:
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/host.access.log;
location / {
auth_basic "simple auth";
auth_basic_user_file /var/kibana_config/htpasswd;
try_files KIBANA #kibana-app;
}
location #kibana-app {
return 301 /api/v1/proxy/namespaces/kube-system/services/kibana-logging/;
}
location /api/v1/proxy/namespaces/kube-system/services/kibana-logging/ {
proxy_set_header Authorization "simple auth ";
proxy_pass http://kibana-logging.kube-system.svc.cluster.local:5601/;
proxy_set_header HOST $host;
proxy_set_header Referer $http_referer;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
}
Going to the URL that K8s created at AWS as an ELB (kibana-app.env.com) redirects to /api/v1/proxy/namespaces/kube-system/services/kibana-logging/ which proxy_pass to kibana pod : http://kibana-logging.kube-system.svc.cluster.local:5601
I'm setting up a web/app/db stack, and the nginx proxy configuration isn't working the way I thought it would.
so here is an example of the stack...the url of the application is:
https://testapp.com
here is the nginx config:
server {
listen 8886;
server_name _;
root /usr/share/nginx/html;
include /etc/nginx/default.d/*.conf;
#ELB
if ($http_user_agent = 'ELB-HealthChecker/2.0') {
return 200 working;
}
#HTTP to HTTPS
if ($http_x_forwarded_proto != 'https') {
return 301 https://$host$request_uri;
}
location / {
set $proxy_upstream_name "testapp.com";
port_in_redirect off;
proxy_pass http://internal-alb.amazonaws.com:8083/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header Access-Control-Allow-Origin $http_origin;}
The app is proxied to an internal AWS alb, and it forwards it to a single (at this point) application server.
I'm able to get the site to serve. However, the application creates a redirect on login, and I get the following response.
Request URL:https://testapp.com/login
Request Method:POST
Status Code:302
Remote Address:34.192.444.29:443
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-language:en-US
content-length:0
date:Mon, 11 Sep 2017 18:35:34 GMT
location:http://testapp.com:8083/testCode
server:openresty/1.11.2.5
status:302
The redirect fails because it's being served on 443, not 8083.
For some reason the app or the proxy isn't updating the port as it doing it's reverse proxy thing, so that the redirect has the proxied port NOT the actual application port 443.
What do I need to do with nginx config to get it to redirect correctly.
thanks.
myles.
The normal behaviour of the nginx is to rewrite the upstream address to the address the page was served from. It looks like instead of using your upstream address (http://internal-alb.amazonaws.com:8083/), your app is responding using a mixture of the two (http://testapp.com:8083). You can either change the app behaviour, or, to fix it at the nginx level, can use the proxy_redirect directive.
I'm reasonably sure the directive to fix this is proxy_redirect http://testapp.com:8083/ https://testapp.com/;
I have 2 servers(CentOS7) in LAN WildflyAPP and nGinX.
nGinX is having 2 eth cards. One connected with LAN(192.X.X.X network) and second up to the wild world (external static IP).
I'm trying to use nGinX as Proxy to Wildfly 8.2.1(as a service) using subdomains:
app.mydomain.com to be used as proxy to Wildfly application (8080 port)
wildfly.mydomain.com for management to wildfly (9000 port)
In both cases im receiving 502 error
I used default configuration for nGinx:
server {
listen 80;
server_name app.mydomain.com;
error_log /var/log/nginx/app-error.log;
access_log /var/log/nginx/app-access.log;
location / {
proxy_pass http://192.X.X.X:8080/;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
add_header Cache-Control "no-cache, no-store";
}
}
I also tried versions with:
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
Nothing i found anywhere in net helped (standalone file checked and looks ok, APP accessible from LAN at 8080 without any problems).
Please help me what i am doing wrong here.