# How to configure Ollama for remote access, and why you need a reverse proxy in front of it > Source: https://netray.co/troubleshoot/ollama-remote-access-configuration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: On-Prem AI Troubleshooting ## Short answer Ollama binds to 127.0.0.1 by default, which blocks any connection from another machine, container, or network. Setting OLLAMA_HOST=0.0.0.0 makes it listen on all interfaces, but Ollama's API has no built-in authentication, so any remote-accessible instance must sit behind a reverse proxy or VPN that adds authentication and TLS before it is exposed beyond a fully trusted local network. ## Error Title Configuring Ollama for remote access safely ## Error Signature curl: (28) Failed to connect to 192.168.1.50 port 11434: Connection timed out ## Alternate Signatures - OLLAMA_HOST=0.0.0.0 still refuses remote connections - Connection refused when accessing Ollama from another machine on the network ## Category local-runtime ## Stack - ollama - docker ## Affects Any Ollama install where clients connect from a different machine, container, or network than the one running the service ## Quick Fix ### Fastest path to safe remote access **Steps:** - Set the environment variable OLLAMA_HOST=0.0.0.0:11434 on the machine running Ollama and restart the service. - Confirm it is listening on all interfaces: ss -tlnp | grep 11434 should show 0.0.0.0:11434, not 127.0.0.1:11434. - Open port 11434 in the firewall only for the specific source IPs or subnet you trust, never for the whole internet. - Put a reverse proxy (nginx, Caddy, or Traefik) in front of Ollama that terminates TLS and enforces basic auth or an API key. - Point remote clients at the reverse proxy's address and port, not directly at 11434. ## Symptoms - curl or an HTTP client from another machine times out or is refused, while it works fine on the Ollama host itself - ss or netstat shows Ollama bound to 127.0.0.1:11434 instead of 0.0.0.0:11434 - A Docker container on the same host cannot reach Ollama running on the host without extra networking configuration - After setting OLLAMA_HOST, remote access still fails because a firewall rule was never updated ## Causes ### OLLAMA_HOST was never set, so Ollama binds to localhost only **Likelihood:** most-common **Explanation:** Ollama's default bind address is 127.0.0.1, a deliberate safety default because the API has no authentication; without explicitly setting OLLAMA_HOST to 0.0.0.0 or a specific reachable interface IP, the socket only accepts connections originating from the same machine, so any remote client is refused at the TCP level regardless of firewall state. **Fix:** Set OLLAMA_HOST=0.0.0.0:11434 as an environment variable for the ollama service and restart it, then verify the bind address with ss -tlnp. **Commands:** - export OLLAMA_HOST=0.0.0.0:11434 - systemctl restart ollama - ss -tlnp | grep 11434 ### Firewall still blocking the port after rebinding **Likelihood:** common **Explanation:** Rebinding to 0.0.0.0 only changes what the process listens on; it does nothing to open the host firewall or a cloud security group, so a remote request can still be dropped before it ever reaches the Ollama process even though the bind address is now correct. **Fix:** Explicitly allow inbound TCP on port 11434 from your trusted subnet in ufw, firewalld, or your cloud provider's security group, and re-test from the remote machine. **Commands:** - sudo ufw allow from 10.0.0.0/8 to any port 11434 ### Exposing Ollama directly to an untrusted network without a proxy **Likelihood:** common **Explanation:** Ollama's API accepts any request that reaches it, with no login, token, or API key by default; opening it directly to a broad network, a public IP, or the open internet means anyone who finds the port can run inference or pull model listings, which is a real data exposure and cost risk, not a theoretical one. **Fix:** Never expose port 11434 directly beyond a fully trusted network. Put nginx, Caddy, or a similar reverse proxy in front that adds TLS and an authentication layer (API key header, basic auth, or OAuth) before forwarding to Ollama. **Commands:** - # nginx: proxy_pass http://127.0.0.1:11434, with an auth_request or API key check in front ### Docker container networking isolating Ollama from the host or other containers **Likelihood:** occasional **Explanation:** A containerized Ollama with default bridge networking is reachable at a container-internal address, not localhost, from other containers or the host; clients using localhost or 127.0.0.1 from outside that container's namespace will fail even though OLLAMA_HOST is correctly set to 0.0.0.0 inside the container. **Fix:** Publish the port explicitly with -p 11434:11434, or use host networking, and have clients connect to the host's actual IP or hostname rather than localhost. **Commands:** - docker run -d -p 11434:11434 -e OLLAMA_HOST=0.0.0.0:11434 ollama/ollama ### Client using the wrong hostname or an outdated DNS/IP entry **Likelihood:** rare **Explanation:** If the Ollama host's IP address changed (common with DHCP or cloud instances being recreated) but the client configuration or a cached DNS entry still points at the old address, connections will time out even though the server itself is correctly configured for remote access. **Fix:** Confirm the current IP or hostname of the Ollama host and update client configuration, or assign a static IP or DNS name to avoid this recurring. **Commands:** - hostname -I ## Diagnostics ### Check the actual bind address **Command:** ss -tlnp | grep 11434 **Interpretation:** 0.0.0.0:11434 means it is listening on all interfaces; 127.0.0.1:11434 means only local connections work regardless of firewall state. ### Test connectivity from the remote client **Command:** curl -v http://:11434/api/tags **Interpretation:** Connection refused means the port is reachable but nothing is listening correctly there; connection timed out usually means a firewall or security group is dropping the packets silently. ### Verify the environment variable took effect **Command:** systemctl show ollama -p Environment **Interpretation:** Confirms whether OLLAMA_HOST is actually set in the running service's environment, since a typo or a config file that was not reloaded is a common reason the setting appears ignored. ## Prevention - Never bind Ollama's API to 0.0.0.0 without also placing an authenticating reverse proxy in front of it. - Scope firewall rules to specific trusted subnets rather than opening the port broadly, and review them on a schedule. - Use a static IP, internal DNS name, or service discovery entry for the Ollama host so client configuration does not silently rot. - If remote access is only needed occasionally, prefer an SSH tunnel or VPN over a permanently open port. ## When To Escalate The moment more than one team or an external partner needs access to your Ollama instance, or you need audit logs of who queried what, you have outgrown a single bound-and-firewalled Ollama box and need a proper API gateway with authentication, rate limiting, and logging in front of your inference layer. ## Faq ### Is it safe to set OLLAMA_HOST=0.0.0.0 on a cloud VM with a public IP? **Answer:** Not by itself. That setting only controls which network interfaces Ollama listens on; it adds no authentication. Combine it with a firewall or security group that blocks the port from the public internet and a reverse proxy that requires authentication for any traffic you do allow through. ### Does Ollama support API keys or authentication natively? **Answer:** Ollama's core API does not include built-in authentication as of current releases. Any access control has to be added externally, typically through a reverse proxy that checks an API key or token before forwarding requests to Ollama. ### Can I access Ollama remotely without opening any firewall port? **Answer:** Yes, an SSH tunnel forwards the port over an already-authenticated SSH connection without exposing 11434 to the network at all, which is a good option for occasional remote access. ## Search terms ollama remote access, OLLAMA_HOST 0.0.0.0, ollama reverse proxy, ollama api authentication, ollama expose network, ollama security remote --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json