☰

NGINX: la redirección funciona, el pase de proxy no

tag-icon • tag-icon nginx reverse-proxy proxypass
NGINX: la redirección funciona, el pase de proxy no

Así que estoy intentando configurar un proxy inverso y me encontré con un error extraño: cuando redirijo al usuario, todo funciona bien, pero cuando uso proxy_pass (como lo necesito) aparece un "Error 502 de puerta de enlace incorrecta".

Código:

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;

    }

Después de capturar el tráfico, descubrí que el par, después de completar el protocolo de enlace de tres vías, cierra inmediatamente la conexión una vez que recibe la solicitud http.

Entonces, ¿qué podría estar causando este error?

Archivo de registro de errores

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

Gracias

Respuesta1

Entonces, después de aproximadamente 2 días de pensar en esto (y con algo de ayuda), descubrimos que era un problema de enrutamiento. Los firewalls parecen estar descartando silenciosamente los paquetes para esta comunicación por alguna razón (no tenemos ninguna regla que haga esto).

información relacionada