Nginx reverse proxy: aplikacja HTTP i WebSocket

Najpierw sprawdź aplikację

Proxy nie uruchamia programu za Ciebie. Zanim zmienisz konfigurację Nginx, potwierdź odpowiedź aplikacji pod jej wewnętrznym adresem, np. curl -I http://127.0.0.1:3000/. Jeżeli proxy działa w innym kontenerze, jego 127.0.0.1 oznacza ten kontener, nie hosta ani sąsiednią usługę.

Dodaj właściwy host i lokalizację

Poniższy fragment należy do bloku server wybranego hosta. Przykład jawnie używa HTTP/1.1, co jest przydatne również przy starszych wersjach Nginx. Portu aplikacji nie trzeba przez to udostępniać całemu Internetowi.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /socket/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Dopasuj /socket/ do ścieżki aplikacji. Ukośnik na końcu adresu w proxy_pass może zmienić sposób przekazania ścieżki; nie dodawaj go przypadkowo.

Testuj przed przeładowaniem

sudo nginx -t
# Przeładuj dopiero po poprawnym teście:
sudo systemctl reload nginx

Sprawdź zarówno zwykły HTTP, jak i ustanowienie połączenia WebSocket. Długie połączenie może wymagać heartbeatów aplikacji i dopasowania timeoutu. Sam kod 200 ze strony głównej nie potwierdza działania kanału WebSocket.

Rozdziel warstwy podczas diagnozy

• 404 z panelu pośrednika: sprawdź przypisanie nazwy hosta, nie tylko rekord DNS.
• 502: sprawdź adres upstream, port, proces i sieć kontenerów.
• Błąd TLS: porównaj certyfikat, nazwę hosta i tryb połączenia z originem.
• Aplikacja może ufać nagłówkom proxy wyłącznie od zaufanych pośredników; nie traktuj dowolnego X-Forwarded-For jako tożsamości klienta.

Czytaj dalej