🔄 Jak skonfigurować serwer Nginx jako serwer proxy dla aplikacji webowych
Nginx to potężny, wydajny i elastyczny serwer WWW, ale jego prawdziwa moc ujawnia się, gdy wykorzystasz go jako serwer proxy odwrotny. W tym kompletnym przewodniku dowiesz się krok po kroku, jak skonfigurować Nginx jako proxy dla różnych aplikacji webowych, zapewniając wysoką wydajność, load balancing i bezpieczeństwo swoich usług.
⚡ Ekspresowe Podsumowanie:
- Proxy odwrotne Nginx zwiększa bezpieczeństwo i wydajność aplikacji webowych działając jako pośrednik między klientami a serwerami aplikacji.
- Podstawowa konfiguracja proxy wymaga tylko kilku linii w bloku
server
z dyrektywąproxy_pass
. - Zaawansowane funkcje obejmują load balancing, buforowanie, kompresję i terminację SSL.
- Bezpieczeństwo wzmacnia dodanie nagłówków, limitowanie żądań i ochrona przed popularnymi atakami.
🗺️ Spis Treści - Twoja Mapa Drogowa
📚 Wprowadzenie do proxy odwrotnego w Nginx
Zanim przejdziemy do praktycznych przykładów konfiguracji, warto zrozumieć, czym jest proxy odwrotne i dlaczego Nginx świetnie się w tej roli sprawdza.
Co to jest proxy odwrotne?
Proxy odwrotne (ang. reverse proxy) to serwer pośredniczący, który przyjmuje żądania od klientów i przekazuje je do odpowiednich serwerów aplikacji w tle. Następnie zwraca odpowiedzi z tych serwerów do klientów, działając jak "tłumacz" i "bramkarz".
Kiedy serwer działa jako proxy odwrotne:
- Klienci łączą się tylko z serwerem proxy, nie znając faktycznej struktury sieci wewnętrznej
- Serwer proxy decyduje, gdzie skierować ruch
- Można zaimplementować zaawansowane funkcje jak load balancing, buforowanie i SSL
Dlaczego warto używać Nginx jako proxy?
Nginx został zaprojektowany od podstaw z myślą o wysokiej wydajności i małym zużyciu zasobów, co czyni go idealnym kandydatem na serwer proxy:
- Wysoka wydajność - obsługuje dziesiątki tysięcy jednoczesnych połączeń
- Mała konsumpcja zasobów - działa wydajnie nawet na ograniczonym sprzęcie
- Zaawansowana obsługa HTTP/HTTPS - wsparcie dla HTTP/2, WebSockets, itp.
- Wsparcie dla mikrousług - łatwe zarządzanie wieloma aplikacjami webowymi
💻 Instalacja Nginx
Rozpoczniemy od instalacji Nginx na serwerze. Poniżej znajdziesz instrukcje dla najpopularniejszych dystrybucji Linuxa:
Dla Ubuntu/Debian:
sudo apt update
sudo apt install nginx
Dla CentOS/RHEL:
sudo yum install epel-release
sudo yum install nginx
Sprawdzenie instalacji:
Po zainstalowaniu, uruchom Nginx i sprawdź jego status:
sudo systemctl start nginx
sudo systemctl status nginx
Powinieneś zobaczyć komunikat potwierdzający, że serwis jest aktywny i działa.
Otwórz przeglądarkę i przejdź pod adres IP swojego serwera. Powinieneś zobaczyć domyślną stronę powitalną Nginx.
✨ Pro Tip: Po pierwszej instalacji zawsze sprawdź, czy zapora (firewall) pozwala na ruch HTTP/HTTPS:
sudo ufw allow 'Nginx Full' # dla Ubuntu z UFW
sudo firewall-cmd --permanent --add-service=http --add-service=https # dla CentOS z firewalld
sudo firewall-cmd --reload
🔧 Podstawowa konfiguracja proxy w Nginx
Przejdźmy teraz do konfiguracji Nginx jako serwera proxy odwrotnego. Zacznijmy od najprostszego przypadku - przekierowania ruchu do pojedynczej aplikacji webowej działającej lokalnie.
Struktura plików konfiguracyjnych Nginx
Zanim zaczniemy edytować konfigurację, warto poznać strukturę plików Nginx:
- /etc/nginx/nginx.conf - główny plik konfiguracyjny
- /etc/nginx/sites-available/ - katalog z konfiguracjami poszczególnych stron/aplikacji
- /etc/nginx/sites-enabled/ - dowiązania symboliczne do aktywnych konfiguracji
- /var/log/nginx/ - logi Nginx
Tworzenie podstawowej konfiguracji proxy
Załóżmy, że mamy aplikację webową działającą na localhost:3000 (np. aplikację Node.js, Python Flask, Ruby on Rails itp.) i chcemy udostępnić ją na standardowym porcie HTTP.
Utwórz nowy plik konfiguracyjny:
sudo nano /etc/nginx/sites-available/app-proxy.conf
Dodaj następującą konfigurację:
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
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_cache_bypass $http_upgrade;
}
}
Co oznaczają poszczególne dyrektywy?
- proxy_pass - określa adres, do którego przekazywane będą żądania
- proxy_http_version - ustawia wersję protokołu HTTP
- proxy_set_header - ustawia lub modyfikuje nagłówki HTTP przesyłane do serwera aplikacji
- proxy_cache_bypass - warunki, kiedy Nginx powinien ominąć pamięć podręczną
Aktywacja konfiguracji
Po utworzeniu pliku konfiguracyjnego, utwórz dowiązanie symboliczne do katalogu sites-enabled:
sudo ln -s /etc/nginx/sites-available/app-proxy.conf /etc/nginx/sites-enabled/
Sprawdź poprawność konfiguracji:
sudo nginx -t
Jeśli test zakończy się sukcesem, zrestartuj Nginx:
sudo systemctl reload nginx
Po tej operacji wszystkie żądania kierowane na Twoją domenę będą przekazywane do lokalnej aplikacji działającej na porcie 3000.
🔀 Konfiguracja proxy dla wielu aplikacji
W rzeczywistych scenariuszach często potrzebujemy obsługiwać wiele aplikacji na jednym serwerze. Nginx doskonale radzi sobie z takim zadaniem.
Na podstawie ścieżki (path-based routing)
Możemy kierować różne ścieżki URL do różnych aplikacji:
server {
listen 80;
server_name example.com www.example.com;
# Aplikacja główna
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# Panel administracyjny
location /admin {
proxy_pass http://localhost:3001;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# API
location /api {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
W tej konfiguracji:
example.com/
będzie obsługiwane przez aplikację na porcie 3000example.com/admin
będzie obsługiwane przez aplikację na porcie 3001example.com/api
będzie obsługiwane przez aplikację na porcie 8080
Na podstawie domen (domain-based routing)
Alternatywnie, możemy kierować ruch na podstawie nazwy domeny:
# Aplikacja główna
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
# Panel administracyjny
server {
listen 80;
server_name admin.example.com;
location / {
proxy_pass http://localhost:3001;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
# API
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
W tej konfiguracji każda subdomena kieruje do innej aplikacji.
⚖️ Load Balancing dla wysokiej dostępności
Jedną z najpotężniejszych funkcji Nginx jako proxy jest możliwość zrównoważenia obciążenia (load balancing) między wieloma serwerami aplikacji.
Podstawowa konfiguracja load balancingu
# Definicja grupy serwerów
upstream app_servers {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
server 192.168.1.12:3000;
}
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://app_servers;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
W tej konfiguracji ruch będzie równomiernie rozdzielany między trzy serwery aplikacji.
Zaawansowane opcje load balancingu
Nginx oferuje kilka algorytmów zrównoważenia obciążenia:
Round Robin (domyślny)
upstream app_servers {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
server 192.168.1.12:3000;
}
Żądania są kierowane po kolei do każdego serwera.
Least Connections
upstream app_servers {
least_conn;
server 192.168.1.10:3000;
server 192.168.1.11:3000;
server 192.168.1.12:3000;
}
Żądania są kierowane do serwera z najmniejszą liczbą aktywnych połączeń.
IP Hash
upstream app_servers {
ip_hash;
server 192.168.1.10:3000;
server 192.168.1.11:3000;
server 192.168.1.12:3000;
}
Ta metoda zapewnia, że ten sam klient zawsze trafia do tego samego serwera (przydatne dla sesji).
Wagi serwerów
upstream app_servers {
server 192.168.1.10:3000 weight=5;
server 192.168.1.11:3000 weight=3;
server 192.168.1.12:3000 weight=2;
}
Serwery z wyższą wagą otrzymują proporcjonalnie więcej ruchu.
Sprawdzanie stanu serwerów (Health Checks)
upstream app_servers {
server 192.168.1.10:3000 max_fails=3 fail_timeout=30s;
server 192.168.1.11:3000 max_fails=3 fail_timeout=30s;
server 192.168.1.12:3000 max_fails=3 fail_timeout=30s;
}
Parametry:
- max_fails - liczba nieudanych prób, po których serwer jest oznaczany jako niedostępny
- fail_timeout - czas, przez który serwer jest oznaczony jako niedostępny po max_fails nieudanych próbach
🔒 Konfiguracja HTTPS dla Nginx proxy
Jedną z kluczowych zalet używania Nginx jako proxy jest możliwość centralizacji obsługi HTTPS. Nginx może obsługiwać szyfrowanie SSL/TLS, odciążając serwery aplikacji.
Uzyskanie certyfikatu SSL
Najłatwiejszym sposobem na zdobycie darmowego certyfikatu SSL jest użycie Let's Encrypt:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
Ręczna konfiguracja HTTPS
Jeśli masz już certyfikat SSL, możesz skonfigurować HTTPS ręcznie:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /path/to/certificate.crt;
ssl_certificate_key /path/to/private.key;
# Optymalne ustawienia SSL
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
# HSTS (optional)
add_header Strict-Transport-Security "max-age=63072000" always;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
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;
}
}
W tej konfiguracji:
- Przekierowujemy cały ruch HTTP na HTTPS
- Konfigurujemy SSL z silnym szyfrowaniem
- Włączamy HTTP/2 dla lepszej wydajności
✨ Pro Tip: Zawsze sprawdzaj bezpieczeństwo swojej konfiguracji SSL używając narzędzi online, takich jak SSL Labs.
🚀 Optymalizacja wydajności proxy Nginx
Proxy ma znaczący wpływ na wydajność Twojej aplikacji. Oto jak zoptymalizować swoją konfigurację proxy:
Buforowanie odpowiedzi (Caching)
# Definicja strefy buforowania
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://localhost:3000;
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
}
}
Kluczowe dyrektywy:
- proxy_cache_path - definiuje ścieżkę do plików cache
- proxy_cache - włącza buforowanie dla lokalizacji
- proxy_cache_valid - określa czas ważności odpowiedzi w pamięci podręcznej
- proxy_cache_use_stale - pozwala używać starych danych z cache, gdy serwer nie odpowiada
Kompresja treści (Gzip)
# Włączenie kompresji w głównym pliku nginx.conf
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
application/javascript
application/json
application/xml
application/xml+rss
text/css
text/javascript
text/plain
text/xml;
server {
# Pozostała konfiguracja...
}
Buforowanie połączeń
upstream app_servers {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
keepalive 32;
}
server {
# ...
location / {
proxy_pass http://app_servers;
proxy_http_version 1.1;
proxy_set_header Connection "";
# ...
}
}
Dyrektywa keepalive
w bloku upstream pozwala na ponowne wykorzystanie połączeń, co znacząco zwiększa wydajność.
Optymalizacja buforów
server {
# ...
location / {
proxy_pass http://localhost:3000;
# Optymalne wartości buforów
proxy_buffer_size 16k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
# ...
}
}
🛡️ Zabezpieczanie Nginx proxy
Nginx może działać jako pierwsza linia obrony dla Twoich aplikacji. Oto jak go zabezpieczyć:
Podstawowe nagłówki bezpieczeństwa
server {
# ...
location / {
proxy_pass http://localhost:3000;
# Nagłówki bezpieczeństwa
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self';" always;
# ...
}
}
Ograniczanie liczby połączeń
# Definicja limitów w głównej sekcji http
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;
server {
# ...
location / {
proxy_pass http://localhost:3000;
# Limitowanie połączeń
limit_conn conn_limit_per_ip 10;
limit_req zone=req_limit_per_ip burst=20 nodelay;
# ...
}
}
Blokowanie niepożądanych żądań
server {
# ...
# Blokowanie dostępu do plików ukrytych
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
# Blokowanie niebezpiecznych typów plików
location ~* \.(bak|swp|bak|old)$ {
deny all;
access_log off;
log_not_found off;
}
# ...
}
Blokowanie botów i niechcianych użytkowników
# Zablokuj dostęp dla złośliwych botów (fragment)
map $http_user_agent $bad_bot {
default 0;
~*crawl|~*bot|~*spider|~*slurp|~*scrap 1;
}
server {
# ...
if ($bad_bot) {
return 403;
}
# ...
}
📝 Obsługa WebSockets przez proxy
Wiele nowoczesnych aplikacji wykorzystuje WebSockets do komunikacji w czasie rzeczywistym. Nginx może przekazywać ruch WebSocket do serwerów aplikacji.
server {
# ...
location /websocket/ {
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_set_header X-Real-IP $remote_addr;
proxy_read_timeout 3600s; # Dłuższy timeout dla połączeń WebSocket
proxy_send_timeout 3600s;
}
# ...
}
📊 Monitorowanie i debugowanie Nginx proxy
Aby utrzymać optymalną wydajność proxy, konieczne jest jego monitorowanie i debugowanie.
Konfiguracja logów dla proxy
server {
# ...
# Dostosowane logi z informacjami o proxy
access_log /var/log/nginx/proxy_access.log combined_proxy;
error_log /var/log/nginx/proxy_error.log warn;
# ...
}
Dodaj własny format logowania w głównym pliku konfiguracyjnym:
# W sekcji http nginx.conf
log_format combined_proxy '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct=$upstream_connect_time uht=$upstream_header_time urt=$upstream_response_time';
Ten format loguje dodatkowe informacje potrzebne do monitorowania wydajności proxy.
Podstawowe debugowanie
-
Sprawdź status Nginx:
sudo systemctl status nginx
-
Sprawdź konfigurację pod kątem błędów:
sudo nginx -t
-
Monitoruj logi w czasie rzeczywistym:
sudo tail -f /var/log/nginx/error.log
-
Sprawdź stan połączeń:
sudo netstat -tuln | grep LISTEN
Instalacja modułu ngx_http_stub_status
server {
# ...
# Dodaj wewnętrzną lokalizację dla statystyk
location /nginx_status {
stub_status on;
allow 127.0.0.1; # Zezwól tylko na dostęp lokalny
deny all;
}
# ...
}
Teraz możesz sprawdzić statystyki:
curl http://localhost/nginx_status
🌟 Zaawansowane przypadki użycia
Proxy dla aplikacji PHP (PHP-FPM)
server {
listen 80;
server_name example.com www.example.com;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Reverse proxy dla Dockera
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://172.17.0.2:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Proxy dla aplikacji React/Angular z API
server {
listen 80;
server_name example.com www.example.com;
root /var/www/frontend/build;
index index.html;
# Obsługa aplikacji SPA
location / {
try_files $uri $uri/ /index.html;
}
# Przekazanie API do backendu
location /api {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
❓ FAQ - Odpowiedzi na Twoje Pytania
Jaka jest różnica między serwerem proxy a serwerem proxy odwrotnym?
Zwykły serwer proxy (forward proxy) działa w imieniu klientów, wysyłając ich żądania do różnych serwerów. Serwer proxy odwrotny (reverse proxy) działa w imieniu serwerów, odbierając żądania od klientów i kierując je do właściwych serwerów w tle. Zwykły proxy ukrywa tożsamość klienta, a odwrotny proxy ukrywa strukturę sieci wewnętrznej.
Czy Nginx proxy może obsługiwać protokoły inne niż HTTP?
Tak, Nginx może działać jako proxy dla wielu protokołów, w tym HTTPS, WebSocket, FastCGI, uwsgi, SCGI i memcached. W wersji Nginx Plus dostępny jest również moduł do obsługi proxy TCP/UDP.
Jak sprawdzić, czy moja konfiguracja proxy działa poprawnie?
Sprawdź nagłówki odpowiedzi HTTP używając narzędzi takich jak curl lub przez panel deweloperski w przeglądarce. Szukaj nagłówków takich jak X-Forwarded-For
lub X-Real-IP
, które wskazują na działanie proxy.
Jak skonfigurować proxy dla aplikacji wykorzystujących WebSockets?
Kluczowe jest użycie proxy_http_version 1.1
oraz nagłówków Upgrade
i Connection
jak pokazano w sekcji WebSockets powyżej.
Jak zabezpieczyć mój serwer proxy Nginx przed atakami?
Kluczowe środki obejmują: aktualizację do najnowszej wersji Nginx, konfigurację limitów połączeń, ograniczenie dostępu do określonych adresów IP, konfigurację zapory sieciowej, użycie HTTPS z silnymi parametrami bezpieczeństwa oraz regularne monitorowanie logów.
🏁 Podsumowanie - Gotowy do wdrożenia
Nginx jako serwer proxy odwrotny to potężne narzędzie, które może znacząco poprawić wydajność, bezpieczeństwo i skalowalność Twoich aplikacji webowych. Kluczowe korzyści to:
- Zwiększona wydajność dzięki buforowaniu, kompresji i optymalizacjom
- Lepsza skalowalność poprzez load balancing i zarządzanie połączeniami
- Wzmocnione bezpieczeństwo jako warstwa izolacji między klientami a aplikacjami
- Centralizacja SSL/TLS ułatwiająca zarządzanie certyfikatami
- Elastyczne przekierowania ruchu ułatwiające wdrażanie mikrousług
Niezależnie od tego, czy obsługujesz pojedynczą aplikację, czy złożoną infrastrukturę mikrousług, Nginx jako proxy zapewni Ci solidne fundamenty pod niezawodne, wydajne i bezpieczne rozwiązania webowe.
🚀 Potrzebujesz niezawodnego hostingu dla Twoich aplikacji webowych?
Sprawdź ofertę serwerów VPS w IQHost
Nasze serwery VPS są zoptymalizowane pod kątem wydajności, zapewniają pełną kontrolę i doskonale sprawdzają się jako platformy dla konfiguracji z Nginx jako proxy odwrotnym.
Czy ten artykuł był pomocny?
Twoja strona WordPress działa wolno?
Sprawdź nasz hosting WordPress z ultraszybkimi dyskami NVMe i konfiguracją serwera zoptymalizowaną pod kątem wydajności. Doświadcz różnicy już dziś!
Sprawdź ofertę hostingu