~/ / Artykuły o AI / Lokalne LLM na VPS / nginx przed Ollamą: uwierzytelnianie podstawowe, HTTPS i ustawienia dla strumieniowania

nginx przed Ollamą: uwierzytelnianie podstawowe, HTTPS i ustawienia dla strumieniowania

Domyślnie Ollama nasłuchuje na samym serwerze, co jest dla niej najbezpieczniejszym miejscem. Gdy ma być dostępna z innej maszyny, FAQ Ollamy wskazuje serwer proxy, taki jak nginx. Ten artykuł buduje takie rozwiązanie na podstawie dokumentacji nginx: hasło, HTTPS, ustawienia ważne dla odpowiedzi przesyłanych strumieniowo oraz zapora sieciowa, która zamyka pozostałe drzwi.

Opublikowano: 2026-10-26 · 5 min czytania · Sprawdzono z oficjalną dokumentacją Ollamy i nginx w dniu 2026-10-26. Wartości domyślne dyrektyw zależą od wersji nginx, więc sprawdź wersję, której używasz.

Co mówi FAQ Ollamy

FAQ Ollamy mówi, że Ollama uruchamia serwer HTTP i można ją udostępnić za pomocą serwera proxy, takiego jak Nginx. Jego przykład nasłuchuje na porcie 80, ustawia server_name, przekazuje żądania przez proxy_pass http://localhost:11434 i ustawia nagłówek Host na localhost:11434.

Strona FAQ, którą sprawdziliśmy, nie opisuje żadnego uwierzytelniania serwera Ollama. Dlatego hasło musi pochodzić z proxy działającego przed nim. Ollama domyślnie wiąże się z adresem 127.0.0.1 na porcie 11434, więc nginx na tym samym serwerze może się z nią połączyć bez zmiany tego adresu.

Hasło dzięki uwierzytelnianiu podstawowemu

Moduł ngx_http_auth_basic_module ogranicza dostęp, sprawdzając nazwę użytkownika i hasło. Pracę wykonują dwie dyrektywy: auth_basic, której ciąg znaków jest używany jako realm (obszar uwierzytelniania) i która domyślnie ma wartość off, oraz auth_basic_user_file, która wskazuje plik z hasłami.

Dyrektywa	Domyślnie	Co mówi dokumentacja
auth_basic string \| off;	off	Parametr jest używany jako realm uwierzytelniania. Wartość off anuluje ustawienie odziedziczone z wcześniejszego poziomu.
auth_basic_user_file file;	brak	Plik zawiera po jednym wpisie name:password w wierszu, a wiersze zaczynające się od # są komentarzami.

Obsługiwane typy haseł: hasła zaszyfrowane za pomocą crypt() oraz skróty apr1, oba generowane narzędziem htpasswd z Apache lub poleceniem openssl passwd.
Obsługiwana jest także składnia {SCHEME}data. Strona podaje, że PLAIN jest tylko przykładem i nie należy go używać, a SHA, czyli SHA-1 bez soli, również nie powinno być używane, ponieważ jest podatne na ataki z użyciem tablic tęczowych. SSHA to SHA-1 z solą.
Przykład z dokumentacji: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

Strona wymienia htpasswd i openssl passwd, ale nie podaje żadnych poleceń. Powszechnie używane formy, które są nasze, a nie ze strony, to htpasswd -c /etc/nginx/ollama.htpasswd alice, które prosi o hasło, oraz openssl passwd -apr1, które wypisuje skrót do wklejenia po nazwie użytkownika i dwukropku.

Połączenie HTTPS

Nasza interpretacja, nie stwierdzenie z dokumentów: uwierzytelnianie podstawowe wysyła hasło z każdym żądaniem, więc używaj go wyłącznie za HTTPS. Według dokumentacji nginx serwer potrzebuje parametru ssl na swoim gnieździe nasłuchującym oraz lokalizacji certyfikatu i klucza prywatnego.

Dyrektywa	Przykład z dokumentacji
listen	listen 443 ssl;
server_name	server_name www.example.com;
ssl_certificate	ssl_certificate www.example.com.crt;
ssl_certificate_key	ssl_certificate_key www.example.com.key;

Domyślnie nginx używa ssl_protocols TLSv1.2 TLSv1.3 oraz ssl_ciphers HIGH:!aNULL:!MD5, więc ich jawne ustawianie zazwyczaj nie jest potrzebne.
Klucz prywatny powinien być przechowywany w pliku z ograniczonym dostępem, ale musi być odczytywalny dla procesu głównego (master) nginx.
Jeśli przeglądarki zgłaszają błędy dla certyfikatu od znanego urzędu certyfikacji, serwer może musieć wysyłać certyfikaty pośrednie. Certyfikat serwera musi w połączonym pliku występować przed certyfikatami łańcucha, w przeciwnym razie nginx nie uruchomi się i zgłosi błąd key values mismatch.
Strona „Getting started” Let's Encrypt mówi, że jeśli Twój dostawca nie uzyskuje certyfikatów za Ciebie i możesz administrować swoim serwerem, możesz uruchomić klienta ACME, oraz że dla większości osób poleca Certbot.

Ustawienia dla odpowiedzi strumieniowanych i wolnych

Model pisze odpowiedź kawałek po kawałku, a pierwszy kawałek może nadejść dopiero po jakimś czasie, na przykład gdy duży model jest ładowany do pamięci. O tym, jak to wygląda z zewnątrz, decydują trzy ustawienia nginx.

Dyrektywa	Domyślnie	Co mówi dokumentacja
proxy_buffering	on	Gdy buforowanie jest wyłączone, odpowiedź jest przekazywana klientowi synchronicznie, od razu po otrzymaniu. Gdy jest włączone, nginx najpierw zapisuje odpowiedź w buforach.
proxy_read_timeout	60s	Limit czasu jest ustawiany tylko między dwiema kolejnymi operacjami odczytu, a nie dla całej odpowiedzi. Jeśli serwer, do którego trafia proxy, nie prześle niczego w tym czasie, połączenie jest zamykane.
proxy_http_version	1.1 od nginx 1.29.7	Przed 1.29.7 wartością domyślną było 1.0. Dla połączeń keepalive zalecana jest wersja 1.1 lub 2.

Nasza interpretacja, nie stwierdzenie z dokumentów: aby widzieć odpowiedź pojawiającą się w trakcie pisania, wyłącz proxy_buffering dla lokalizacji Ollamy, a jeśli model może milczeć dłużej niż minutę podczas ładowania, zwiększ proxy_read_timeout. Jawne ustawienie proxy_http_version 1.1 jest nieszkodliwe w każdej wersji.

Złożenie wszystkiego w całość

Ta konfiguracja łączy powyższe dyrektywy dla jednej nazwy serwera. To nasza kompozycja z udokumentowanych dyrektyw, więc przed przeładowaniem przetestuj ją poleceniem nginx -t.

Linia	Dlaczego
server {	jeden blok server dla nazwy Ollamy
listen 443 ssl;	HTTPS
server_name ollama.example.com;	Twoja własna nazwa
ssl_certificate /etc/ssl/ollama.crt;	certyfikat, a po nim certyfikaty pośrednie
ssl_certificate_key /etc/ssl/ollama.key;	klucz prywatny, odczytywalny tylko w niezbędnym zakresie
auth_basic "ollama";	włącza hasło
auth_basic_user_file /etc/nginx/ollama.htpasswd;	miejsce, w którym przechowywani są użytkownicy
location / {	wszystko trafia do Ollamy
proxy_pass http://localhost:11434;	z FAQ Ollamy
proxy_set_header Host localhost:11434;	z FAQ Ollamy
proxy_http_version 1.1;	zalecane dla keepalive
proxy_buffering off;	aby odpowiedź była przesyłana strumieniowo
proxy_read_timeout 300s;	pozwala na wolny pierwszy kawałek
}	koniec location
}	koniec server

Zamknij pozostałe drzwi

Proxy pomaga tylko wtedy, gdy nikt nie może dotrzeć do Ollamy ani do aplikacji za nią w inny sposób. Ollama pozostaje pod swoim domyślnym adresem, a zapora sieciowa wpuszcza tylko adresy, z których korzystasz.

Zadanie	Polecenie z dokumentacji Ubuntu
Włącz zaporę sieciową	sudo ufw enable
Zezwól na port	sudo ufw allow 22
Zezwól jednemu adresowi na jeden port	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Zezwól na całą podsieć	zastąp adres przez 192.168.0.0/24
Sprawdź stan	sudo ufw status

Strona Ubuntu mówi, że UFW jest początkowo wyłączona. Nie ma w niej ostrzeżenia przed zablokowaniem sobie dostępu przez SSH. Nasze zalecenie: na serwerze, do którego łączysz się zdalnie, zezwól na swój port SSH, zanim włączysz zaporę sieciową, a port 443 otwieraj tylko dla adresów, które go potrzebują.