How to configure Ollama for remote access, and why you need a reverse proxy in front of it

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.

export OLLAMA_HOST=0.0.0.0:11434
systemctl restart ollama
ss -tlnp | grep 11434

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.

sudo ufw allow from 10.0.0.0/8 to any port 11434

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.

# nginx: proxy_pass http://127.0.0.1:11434, with an auth_request or API key check in front

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.

docker run -d -p 11434:11434 -e OLLAMA_HOST=0.0.0.0:11434 ollama/ollama

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.

hostname -I