Start / Poradniki / Rozwiązywanie problemów / Windows
Windows
Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026
Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM
curl: (7) Failed to connect to 192.168.1.42 port 11434 after 2004 ms: Could not connect to server
ERR_CONNECTION_REFUSED (from a browser on another device)| Jeśli widzisz | Przyczyną jest | Przejdź do |
|---|---|---|
| Działa na samym komputerze, ale nic z zewnątrz się nie łączy | Ollama jest przypięta do 127.0.0.1, czego żadna reguła zapory nie udostępni | Rozwiązanie 1: najpierw ustaw OLLAMA_HOST — zawsze najpierw |
| Ustawiłeś OLLAMA_HOST, a połączenia dalej są odrzucane | Zapora Windows Defender blokuje przychodzący ruch TCP 11434 | Rozwiązanie 2: dodaj regułę przychodzącą o zawężonym zasięgu |
| Działa na domowym Wi-Fi, a w innej sieci już nie | Reguła obejmuje profil Prywatny, a ta sieć jest sklasyfikowana jako Publiczna | Rozwiązanie 2: sprawdź profil i zostaw Publiczny w spokoju |
| Reguła istnieje, a ruch nadal jest odrzucany | Klient VPN albo pakiet bezpieczeństwa innej firmy filtruje przed Defenderem | Rozwiązanie 4: poszukaj drugiej zapory |
| Chcesz mieć do tego dostęp spoza własnej sieci | API Ollamy nie ma żadnego uwierzytelniania | Rozwiązanie 3: zrób tunel — nie przekierowuj portu |
Chcesz, żeby twój telefon, laptop albo kontener na innej maszynie korzystały z modelu na twoim desktopie. Na samym desktopie http://localhost:11434 odpowiada natychmiast. Zewsząd indziej połączenie jest odrzucane, a odruchowa reakcja — otwórz port w zaporze — niczego nie zmienia, bo port nigdy nie był problemem.
Zanim inne urządzenie sięgnie do Ollamy, spełnione muszą być dwa niezależne warunki — a zawodzą w kolejności, która wprowadza ludzi w błąd. Po pierwsze, Ollama domyślnie binduje się do 127.0.0.1:11434, czyli do interfejsu pętli zwrotnej, z założenia nieosiągalnego skądkolwiek poza samą maszyną. Dopóki tak jest, żadna konfiguracja zapory na świecie nie wpuści innego urządzenia, bo pod adresem, do którego mogłoby ono trafić, nic nie nasłuchuje. Po drugie, gdy Ollama nasłuchuje już na wszystkich interfejsach, zapora Windows Defender blokuje niezamówione połączenia przychodzące i potrzebuje jawnej reguły dla TCP 11434. Czytelnicy prawie zawsze próbują najpierw tego drugiego, nie widzą poprawy i błędnie wykluczają zaporę. Zrób to w kolejności, a efekt każdego kroku będzie widoczny.
Ustaw OLLAMA_HOST na 0.0.0.0:11434 w zmiennych środowiskowych użytkownika — przez Ustawienia → System → Informacje → Zaawansowane ustawienia systemu → Zmienne środowiskowe albo poleceniem PowerShella poniżej — a potem zamknij Ollamę z zasobnika systemowego i uruchom ją ponownie z menu Start. Zamknięcie okna nie wystarczy: aplikacja odczytuje tę zmienną wyłącznie przy starcie. Zanim zrobisz to w sieci, nad którą nie masz kontroli, przeczytaj rozwiązanie 3.
# PowerShell — persists for your account
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:11434", "User")
# Quit Ollama from the system tray, relaunch from the Start menu, then:
Get-NetTCPConnection -LocalPort 11434 -State Listen |
Select-Object LocalAddress, LocalPort, State0.0.0.0 (albo ::), a nie 127.0.0.1. Dopóki widnieje tam 127.0.0.1, nic z reszty tej strony nie pomoże.Get-NetTCPConnection -LocalPort 11434 -State Listen | Select-Object LocalAddressTeraz zapora ma znaczenie. W interfejsie graficznym: Zabezpieczenia Windows → Zapora i ochrona sieci → Ustawienia zaawansowane → Reguły przychodzące → Nowa reguła → Port → TCP → 11434, a na stronie profilu zaznacz wyłącznie Prywatny. Jednolinijkowiec w PowerShellu robi to samo za jednym zamachem. Zawężenie do profilu Prywatnego jest tu najważniejsze — reguła obejmująca także profil Publiczny podąża za tobą do każdej niezaufanej sieci, do jakiej się kiedykolwiek podłączysz, a to dokładnie te miejsca, w których nie chcesz mieć nasłuchującego API bez uwierzytelniania.
⚠️ Nie zaznaczaj profilu Publicznego. To profil, który Windows przypisuje sieciom w kawiarniach i hotelach, a to API nie ma żadnego uwierzytelniania — reguła dla profilu Publicznego wystawia je wszystkim w takiej sieci.
# PowerShell as Administrator
New-NetFirewallRule -DisplayName "Ollama API (LAN)" `
-Direction Inbound -Action Allow `
-Protocol TCP -LocalPort 11434 `
-Profile Private
# Tighter still — only one device may connect
New-NetFirewallRule -DisplayName "Ollama API (one host)" `
-Direction Inbound -Action Allow `
-Protocol TCP -LocalPort 11434 `
-Profile Private -RemoteAddress 192.168.1.50curl http://192.168.1.42:11434/api/tagsAPI Ollamy nie ma żadnego uwierzytelniania. Każdy, kto dosięgnie portu 11434, może wypisać twoje modele, liczyć na twoim GPU i pobierać nowe modele na twój dysk — a pobranie to nieuwierzytelniony, wielogigabajtowy zapis na twoją przestrzeń. W zaufanej sieci domowej zawężona reguła powyżej jest rozsądnym kompromisem. We współdzielonej, firmowej, uczelnianej czy publicznej — już nie, a przekierowanie portu na routerze jest jeszcze gorsze. W kolejności, w jakiej je polecamy: tunel SSH, który nie wystawia niczego i działa od zaraz; reverse proxy z uwierzytelnianiem przed API; albo reguła zapory ograniczona do jednego źródłowego adresu IP. Jeśli się wahasz, wybierz tunel — klient dalej rozmawia z localhost, a ruch jest uwierzytelniony i szyfrowany przez SSH.
# bash, from the CLIENT device — nothing is exposed on the network
ssh -N -L 11434:127.0.0.1:11434 you@192.168.1.42
# Then on the client, Ollama is at localhost as usual:
curl http://localhost:11434/api/tagscurl -s http://localhost:11434/api/tags | head -c 200Jeśli Get-NetTCPConnection pokazuje 0.0.0.0, reguła Defendera istnieje, a ruch nadal jest odrzucany, filtruje coś przed nim. Typowi podejrzani to klient VPN, który przy aktywnym połączeniu przekierowuje albo blokuje ruch lokalny, pakiet bezpieczeństwa innej firmy z własną zaporą przejmującą reguły Defendera, oraz — na laptopie firmowym — zasada grupy nadpisująca reguły lokalne w całości. Sprawdź też profil sieci: Windows po niektórych zmianach po cichu przeklasyfikowuje sieć na Publiczną, co dezaktywuje regułę zawężoną do Prywatnej, nie mówiąc ci o tym.
# PowerShell — is this network Private or Public right now?
Get-NetConnectionProfile | Select-Object Name, NetworkCategory
# Is the rule actually enabled and on the right profile?
Get-NetFirewallRule -DisplayName "Ollama API (LAN)" |
Select-Object DisplayName, Enabled, Profile, ActionPrivate, a reguła — Enabled: True, Profile: Private, Action: Allow. Rozbieżność między nimi jest twoją odpowiedzią.To zasługuje na osobny krok, bo ludzie zostawiają je włączone na miesiące. Kiedy zdalny dostęp przestaje być potrzebny — pokaz się skończył, przeszedłeś na tunel, wyjeżdżasz — przywróć bindowanie na pętlę zwrotną i skasuj regułę. Dwa polecenia i maszyna przestaje odpowiadać sieci.
# PowerShell as Administrator
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", $null, "User")
Remove-NetFirewallRule -DisplayName "Ollama API (LAN)"
# Quit Ollama from the tray and relaunch, then confirm:
Get-NetTCPConnection -LocalPort 11434 -State Listen | Select-Object LocalAddress127.0.0.1, a drugie urządzenie dostaje odrzucone połączenie.Jeśli na porcie 11434 nic w ogóle nie nasłuchuje — nawet na pętli zwrotnej — to nie ta strona, tylko ogólna diagnostyka odrzuconych połączeń. Jeśli udostępniasz maszynę pracującą bez monitora, a nie desktop, przy którym siedzisz, stronę operacyjną opisuje poradnik o serwerze linuksowym: reverse proxy, utrzymywanie modelu w pamięci i zapełniający się dysk.
Dołącz to, zgłaszając problem
Get-NetTCPConnection -LocalPort 11434 -State ListenGet-NetConnectionProfile z kategorią sieciBo Ollama domyślnie nasłuchuje na 127.0.0.1, a pętla zwrotna jest nieosiągalna z innych maszyn niezależnie od stanu zapory. Nie ma pod routowalnym adresem niczego, na co reguła mogłaby zezwolić. Najpierw ustaw OLLAMA_HOST na 0.0.0.0:11434, dopiero potem dodaj regułę.
Tylko w sieci, którą kontrolujesz. API nie ma uwierzytelniania, więc każdy, kto dosięgnie portu, może liczyć na twoim GPU i pobierać modele na twój dysk. W zaufanej sieci domowej z regułą dla profilu Prywatnego to rozsądny kompromis; w sieciach współdzielonych i publicznych — nie.
Nie. To publikuje nieuwierzytelnione API w internecie, gdzie znajdą je skanery. Użyj tunelu SSH albo postaw przed nim reverse proxy z uwierzytelnianiem i TLS-em. Dobrym środkiem pośrednim przy regularnym dostępie zdalnym jest VPN albo interfejs Tailscale.
Windows przypisuje każdej sieci profil, a reguła zawężona do Prywatnego nie obowiązuje w sieci sklasyfikowanej jako Publiczna. To reguła działająca prawidłowo. Sprawdź Get-NetConnectionProfile i nie poszerzaj reguły na profil Publiczny tylko po to, żeby problem zniknął.
Dodaj do reguły zapory -RemoteAddress z adresem IP tego urządzenia, żeby tylko ono mogło się łączyć. Najpierw przypisz klientowi stałą rezerwację DHCP, inaczej jego adres się zmieni, a reguła po cichu przestanie pasować. To najwęższa opcja poza tunelem.