# Why Ollama says connection refused, and how to fix it > Source: https://netray.co/troubleshoot/ollama-connection-refused > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: On-Prem AI Troubleshooting ## Short answer Ollama connection refused almost always means the ollama serve process is not running, is listening on a different interface than expected, or is bound to 127.0.0.1 while your client is calling it from another host or container. Start or restart the service, confirm it is listening on 11434, and if you need remote access set OLLAMA_HOST to 0.0.0.0 explicitly. ## Error Title Ollama connection refused when calling the API ## Error Signature curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused ## Alternate Signatures - Error: could not connect to ollama app, is it running? - dial tcp 127.0.0.1:11434: connect: connection refused - requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=11434): Max retries exceeded ## Category local-runtime ## Stack - ollama ## Affects Ollama 0.1.x and later, Linux, macOS, and Windows installs, both native service and Docker deployments ## Quick Fix ### Fix it in 60 seconds **Steps:** - Check whether Ollama is running: ps aux | grep ollama on Linux/macOS or check the tray icon on Windows. - Start it manually if it is not running: ollama serve (or restart the ollama systemd service with systemctl restart ollama). - Confirm it is listening: curl http://127.0.0.1:11434/api/tags should return JSON, not a connection error. - If calling from another container or machine, set OLLAMA_HOST=0.0.0.0:11434 before starting the service and retry. - If still refused, check for a firewall rule blocking port 11434 and allow it for your trusted network. ## Symptoms - curl or any HTTP client to localhost:11434 fails immediately with connection refused - The Ollama desktop app or CLI works fine locally but a script or container calling it over the network fails - ollama list works from the terminal but a separate process cannot reach the API - The error appears right after a reboot or after the machine was updated ## Causes ### The ollama service is not running **Likelihood:** most-common **Explanation:** Ollama runs as a background service (a systemd unit on Linux, a menu bar app on macOS, or a tray app on Windows) that listens on port 11434. If the process crashed, was never started, or was stopped by a system update, there is nothing listening on that port and any connection attempt is refused immediately at the TCP level. **Fix:** Start the service directly with ollama serve in a terminal to see any startup errors, or restart the managed service with systemctl restart ollama on Linux. On macOS or Windows, quit and relaunch the Ollama app from the applications menu. **Commands:** - systemctl status ollama - systemctl restart ollama - ollama serve ### OLLAMA_HOST is bound to localhost only **Likelihood:** common **Explanation:** By default Ollama binds to 127.0.0.1, which only accepts connections originating from the same machine. A request from a Docker container, a different VM, or another host on the network is refused even though the service is healthy, because the kernel never routes that traffic to a loopback-bound socket. **Fix:** Set the environment variable OLLAMA_HOST=0.0.0.0:11434 before starting the service so it binds to all interfaces, then restart Ollama. Pair this with a firewall rule or reverse proxy since it removes the implicit localhost-only protection. **Commands:** - export OLLAMA_HOST=0.0.0.0:11434 - systemctl set-environment OLLAMA_HOST=0.0.0.0:11434 - systemctl restart ollama ### A firewall or security group is blocking port 11434 **Likelihood:** common **Explanation:** Even with the service correctly bound to 0.0.0.0, host firewalls (ufw, firewalld, Windows Defender Firewall) or cloud security groups drop inbound traffic to ports that were never explicitly opened, which produces the same connection-refused or connection-timeout behavior from the client side. **Fix:** Open port 11434 for the specific source network you trust, not for the whole internet. On Ubuntu use ufw, on a cloud VM update the security group or NSG rule. **Commands:** - sudo ufw allow from 10.0.0.0/8 to any port 11434 - sudo firewall-cmd --add-port=11434/tcp --permanent ### Another process is already using port 11434 **Likelihood:** occasional **Explanation:** If a previous Ollama instance did not shut down cleanly, or another application was configured to use the same port, the new Ollama process fails to bind and can exit silently in some install methods, leaving nothing listening even though you just ran the start command. **Fix:** Check what is bound to the port and stop the stale process, or change Ollama's port with OLLAMA_HOST=127.0.0.1:11435 and update your client to match. **Commands:** - sudo lsof -i :11434 - sudo kill ### Calling the API from inside a container without host networking **Likelihood:** rare **Explanation:** A container that calls localhost:11434 is talking to its own network namespace, not the host, so even a healthy host-level Ollama service is unreachable. This produces connection refused inside the container while the host itself works fine. **Fix:** Use host.docker.internal instead of localhost from inside the container on Docker Desktop, run the container with --network host on Linux, or point OLLAMA_HOST at the container-reachable host IP. **Commands:** - curl http://host.docker.internal:11434/api/tags - docker run --network host ollama/ollama ## Diagnostics ### Check if the process is running **Command:** ps aux | grep ollama **Interpretation:** No matching process means the service crashed or was never started; restart it and read the startup log for the real error. ### Check what is listening on the port **Command:** sudo ss -tlnp | grep 11434 **Interpretation:** If nothing is listed, Ollama is not bound to that port at all. If it shows 127.0.0.1:11434, remote clients will be refused; you need 0.0.0.0:11434 for remote access. ### Test the API locally **Command:** curl -v http://127.0.0.1:11434/api/tags **Interpretation:** A JSON list of models confirms the service is healthy locally; a connection refused here means the service itself is down, not a networking issue. ### Check the service logs **Command:** journalctl -u ollama -n 50 --no-pager **Interpretation:** Look for bind errors, permission errors, or crash stack traces that explain why the process exited after starting. ## Prevention - Run Ollama as a managed systemd service (or the official Docker image) rather than a manual background process, so it restarts automatically on crash or reboot. - Document your intended OLLAMA_HOST value in your deployment scripts instead of relying on the default, so binding behavior is explicit and reviewed. - Add a basic health check (curl to /api/tags) to your deployment or monitoring pipeline so a dead service is caught before a user hits it. - Keep firewall rules for port 11434 scoped to specific subnets, and review them whenever you move Ollama to a new host. ## When To Escalate If connection refused persists across multiple hosts, or you find yourself opening 11434 to broad network ranges just to make things work, that is a sign you need a proper reverse proxy with authentication and TLS rather than ad hoc firewall rules, which is an architecture decision worth getting right before you have real users depending on it. ## Faq ### Does restarting my computer fix Ollama connection refused? **Answer:** Sometimes, because a reboot restarts the Ollama service along with everything else, but if the underlying cause is a wrong OLLAMA_HOST binding or a firewall rule, the error will return as soon as another process tries to reach it remotely. Treat a reboot as a temporary workaround, not a fix. ### Why does curl localhost:11434 work but my Python script fail? **Answer:** This usually means the Python script is running inside a container or environment with a different network namespace than your shell, or it is pointed at a different host or port than the one Ollama is actually bound to. Print the exact URL your client is using and compare it to ss -tlnp output. ### Is it safe to bind Ollama to 0.0.0.0? **Answer:** Only on a trusted network, because Ollama's API has no built-in authentication. Binding to 0.0.0.0 without a firewall rule or reverse proxy in front of it exposes model inference, and potentially your prompts, to anyone who can reach that port. ### What port does Ollama use by default? **Answer:** 11434 for the HTTP API. You can change it by setting OLLAMA_HOST to a different host:port combination, but make sure every client and container that talks to Ollama is updated to match. ## Search terms ollama connection refused, ollama could not connect, ollama port 11434, OLLAMA_HOST, ollama serve not running, ollama api connection error, ollama firewall, ollama remote access --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json