☰

NGINX - Umleitung funktioniert, Proxy-Pass nicht

tag-icon • tag-icon nginx reverse-proxy proxypass
NGINX - Umleitung funktioniert, Proxy-Pass nicht

Ich versuche also, einen Reverse-Proxy einzurichten, und bin auf einen seltsamen Fehler gestoßen: Wenn ich den Benutzer umleite, funktioniert alles einwandfrei, aber wenn ich proxy_pass verwende (wie ich es brauche), erhalte ich einen „502 Bad Gateway-Fehler“.

Code:

server { #banca empresas HTTP

            listen 80;

            server_name emp.baiq.pt www.emp.baiq.pt;

            rewrite ^ https://$server_name$request_uri? permanent;

    }

    server { #banca empresas HTTPS

            listen 443;

            server_tokens off;

            server_name emp.baiq.pt www.emp.baiq.pt;

            add_header X-Frame-Options SAMEORIGIN;
            add_header X-Content-Type-Options nosniff;
            add_header X-XSS-Protection "1; mode=block";

            ssl_certificate /etc/nginx/certs/*.baiteste.pt.crt;
            ssl_certificate_key /etc/nginx/certs/*.baiteste.pt.key;

            location / {
                    #proxy_pass http://192.168.1.78:8081/login.htm?origin=E;
                    return 301 http://192.168.1.78:8081/login.htm?origin=E;
            }

            #error_page 500 502 503 504 /maintenance_page/index.html;

            location = /maintenance_page/index.html {
                    root html;
            }

            location = /favicon.ico {
                    log_not_found off;
            }

            access_log /var/log/nginx/emp.baiq.pt.access.log;

    }

Nachdem ich den Datenverkehr erfasst hatte, fand ich heraus, dass der Peer nach Abschluss des 3-Wege-Handshakes die Verbindung sofort schließt, sobald er die HTTP-Anfrage empfängt.

Was also könnte die Ursache dieses Fehlers sein?

Fehlerprotokolldatei

2019/07/24 08:25:40 [error] 24506#24506: *2 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: mydomain.com, request: "GET / HTTP/1.1", upstream: "http://y.y.y.y:8081/", host: domaintoaccess.com

Danke

Antwort1

Nachdem ich also etwa zwei Tage darüber nachgedacht hatte (und mit etwas Hilfe), fand ich/fanden wir heraus, dass es sich um ein Routing-Problem handelte. Die Firewalls scheinen die Pakete für diese Kommunikation aus irgendeinem Grund stillschweigend zu verwerfen (wir haben keine Regeln, die das tun).

verwandte Informationen