Co dostajesz z tego buildera
Jeśli kiedyś otworzyłeś pusty plik `.conf` w `/etc/nginx/sites-available/` i nie wiedziałeś, od czego zacząć, to narzędzie jest dla Ciebie. Pisze cały server-block dla pięciu rzeczy, które ludzie naprawdę robią z nginxem: serwowanie strony statycznej, postawienie reverse proxy przed aplikacją, przekierowanie domeny, subdomena, albo rozdzielenie ruchu na wiele backendów z load balancerem.
Wybierz tryb u góry, wpisz domenę i backend, włącz przełączniki dla SSL, gzipa, WebSocketów i Cloudflare. Prawy panel pokazuje dokładny tekst do wklejenia w nginxa, z wcięciami i stylizacją jak prawdziwy config. Skopiuj albo pobierz jako `<twoja-domena>.conf`.
Wszystko działa w przeglądarce. Żadne domeny się nie rozwiązują, żadne certyfikaty się nie wystawiają, nic nie jest wysyłane. Wynik to czysta składnia nginx, identyczna z tym, co napisałbyś ręcznie, gdybyś pamiętał każdą dyrektywę.
Jak używać
- Wybierz tryb u góry: *Strona statyczna*, *Reverse proxy*, *Przekierowanie*, *Subdomena* albo *Load balancer*. Każdy tryb pokazuje tylko pola, które mają sens dla niego.
- Wpisz swoje domeny w server_name. Jedna domena na linię. Pierwsza jest używana jako nazwa certyfikatu.
- Wybierz port listen. 80 dla zwykłego HTTP, 443 dla HTTPS, 8080 gdy proxy wyższego poziomu albo Docker robi TLS za niego.
- Włącz Dodaj blok SSL, żeby podpiąć ścieżki Let's Encrypt (`/etc/letsencrypt/live/<domena>/fullchain.pem`). Zostaw Dodaj przekierowanie HTTP → HTTPS włączone, żeby goście na zwykłym HTTP byli odbijani na https kodem `301`.
- Dla Reverse proxy: ustaw proxy_pass na swój backend, np. `http://127.0.0.1:3000`. Zostaw nagłówki X-Forwarded- włączone, żeby Twoja aplikacja widziała prawdziwe IP klienta.
- Dla Load balancera: wklej `adres:port` w każdej linii w *Lista serwerów backendu* i wybierz algorytm. Używaj grup upstream z `least_conn` dla wolnych aplikacji i `ip_hash`, gdy potrzebujesz sticky sessions.
- Jeśli Twoja aplikacja używa WebSocketów (Socket.IO, Phoenix Channels, itd.), włącz Dodaj nagłówki WebSocket Upgrade. Jeśli stawiasz nginxa za Cloudflare, włącz Dodaj real IP od Cloudflare, żeby logi pokazywały prawdziwego klienta.
- Kliknij Kopiuj, wklej do `/etc/nginx/sites-available/<nazwa>.conf`, zrób symlink do `sites-enabled`, uruchom `sudo nginx -t` żeby zwalidować składnię, potem `sudo systemctl reload nginx`.
Kiedy się przydaje
Siedem sytuacji, w których gotowy server-block oszczędza dużo czasu z dokumentacją:
- Wdrożyłeś aplikację Node, Python albo Go na VPS-ie i chcesz ją postawić na porcie 443 z prawdziwym certyfikatem TLS. Wybierz *Reverse proxy*, wskaż `http://127.0.0.1:3000`, włącz SSL, gotowe. Nginx kończy TLS, Twoja aplikacja siedzi za nim na czystym HTTP.
- Kupiłeś domenę dla statycznego landing page. Wybierz *Strona statyczna*, wskaż root na `/var/www/twoja-strona` i dostajesz działający server-block z dobrymi plikami index i fallbackiem try_files.
- Migrujesz starą domenę na nową. Wybierz *Przekierowanie*, cel `https://new.example.com$request_uri`, kod `301`. Google aktualizuje indeks, przeglądarki cache'ują przekierowanie, stare linki dalej działają.
- Chcesz subdomenę dla bloga. Wybierz *Subdomena*, prefiks `blog`, baza `example.com` i dostajesz kompletny server-block dla `blog.example.com`. Zapisz pod dokładnie taką nazwą pliku, żeby `sites-available/` było uporządkowane.
- Twoja aplikacja nie wyrabia z obciążeniem na jednej maszynie. Wybierz *Load balancer*, wklej trzy albo cztery linie `adres:port`, wybierz `least_conn` i nginx kieruje każde żądanie do najmniej zajętego serwera. Dodanie kolejnego serwera to jedna linia.
- Twój real-time chat się sypie za nginxem z powodu WebSocketów. Włącz *Dodaj nagłówki WebSocket Upgrade* i nginx prawidłowo przekazuje `Upgrade` i `Connection`, z 24h timeoutem na odczyt, który przeżyje długotrwałe połączenia.
- Siedzisz za Cloudflare i wszystkie logi pokazują "172.x.x.x". Włącz *Dodaj real IP od Cloudflare*, nginx przepisuje `$remote_addr` z nagłówka `CF-Connecting-IP` przychodzącego z zakresów Cloudflare. Rate limity, fail2ban i logi audytowe znowu działają.