Expose Ollama on the Network: Port, Bind Address and Hardening

Ollama listens on 127.0.0.1:11434 after installation, so a second machine on the same network gets connection refused no matter how the client is configured. Changing that is one environment variable, but it turns an unauthenticated local API into an unauthenticated network API. This tutorial covers both halves: setting the bind address and port, and locking the endpoint down afterwards.

Why is Ollama not reachable from other hosts?

Ollama binds to the loopback address 127.0.0.1 on TCP port 11434 by default, which means the HTTP API accepts connections only from the machine it runs on and rejects every request arriving over a network interface.

That default is deliberate. The Ollama HTTP API ships without authentication and without rate limiting. Any client that can reach port 11434 can list models, run inference, pull gigabytes of new weights through /api/pull and remove existing ones through /api/delete. Exposing the port is a decision that needs a matching access control, not a formality.

Prerequisites

• A Linux host with Ollama installed. Check with ollama --version; the paths and variables below apply to 0.5.x and later.
• Root or sudo access on that host.
• systemd as the init system. The official install script registers ollama.service.
• For GPU-backed inference, a host with a CUDA-capable card, for example a GPU instance for LLM inference.
• A firewall you control: ufw, nftables, or a security group in front of the host.

What does OLLAMA_HOST control?

OLLAMA_HOST sets the address and port the Ollama server binds to and accepts values such as 0.0.0.0:11434, 192.168.10.5:11434, [::]:11434 or a bare port like :11500; unset, it falls back to 127.0.0.1:11434.

The same variable is read by the ollama CLI to decide which server to talk to. On a workstation, OLLAMA_HOST=http://10.0.0.5:11434 ollama list queries the remote host instead of the local one. One name, two roles, depending on whether it is set for the server process or for a client invocation.

Change the bind address and port

Do not edit /etc/systemd/system/ollama.service directly. A package update overwrites it. Use a drop-in instead:

$ sudo systemctl edit ollama.service

This opens /etc/systemd/system/ollama.service.d/override.conf. Add the environment block:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

To move the service to a different port, change the value to 0.0.0.0:11500. To bind to exactly one interface instead of all of them, name the address: Environment="OLLAMA_HOST=10.0.0.5:11434". That is the narrower option and the better default on a host with both a public and a private NIC.

Apply the change:

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama.service

Verify the listener

Confirm the socket is bound where you expect before touching the firewall:

$ ss -tlnp | grep 11434
LISTEN 0 4096 *:11434 *:* users:(("ollama",pid=1423,fd=3))

A line showing 127.0.0.1:11434 means the drop-in was not picked up. Check what systemd actually passes to the process:

$ systemctl show ollama.service -p Environment
Environment=OLLAMA_HOST=0.0.0.0:11434 OLLAMA_ORIGINS=https://chat.example.com

Then call the API from a second machine on the same network:

$ curl -s http://10.0.0.5:11434/api/tags
{"models":[{"name":"llama3.2:latest","model":"llama3.2:latest","size":2019393189}]}

An empty models array is a valid answer on a fresh host. It still proves the port is reachable.

Restrict who can reach port 11434

At this point the API answers anyone who can route to the host. Close it down to the subnets that actually need inference. With ufw and a default deny policy for incoming traffic, a single allow rule is enough:

$ sudo ufw default deny incoming
$ sudo ufw allow from 10.0.0.0/24 to any port 11434 proto tcp
$ sudo ufw status numbered

The equivalent in nftables:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip saddr 10.0.0.0/24 tcp dport 11434 accept
  }
}

A firewall rule limits who can connect. It does not tell two clients from the same subnet apart, and it does not encrypt anything. For traffic that leaves a trusted network, add a proxy.

Put an authenticating reverse proxy in front

The stable pattern is to leave Ollama on 127.0.0.1:11434 and let nginx own the public port. TLS, credentials and request limits live in the proxy; the model runner never sees an untrusted connection directly.

graph TD
  A["Client or app"] -->|"HTTPS + Basic Auth"| B["nginx :443"]
  B -->|"HTTP to 127.0.0.1:11434"| C["ollama serve"]
  C --> D["GPU model runner"]
  E["Public internet"] -.->|"dropped by firewall"| C

Revert OLLAMA_HOST to 127.0.0.1:11434 in the drop-in when the proxy runs on the same host. Then create the credentials file:

$ sudo apt install -y apache2-utils
$ sudo htpasswd -c /etc/nginx/ollama.htpasswd ollama-client

The server block in /etc/nginx/sites-available/ollama.conf:

server {
    listen 443 ssl;
    server_name ollama.example.com;
    ssl_certificate     /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;
    client_max_body_size 64m;
    location / {
        auth_basic "ollama";
        auth_basic_user_file /etc/nginx/ollama.htpasswd;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

Three settings matter more than the rest. proxy_buffering off keeps streamed tokens flowing to the client instead of collecting them in nginx. proxy_read_timeout 600s covers long generations on large models, which otherwise die at the 60 second default. Rewriting Host to 127.0.0.1:11434 matters because Ollama validates the origin of incoming requests and answers 403 Forbidden when the forwarded hostname is not on its allow list. Alternatively, keep the external hostname and list it in OLLAMA_ORIGINS.

If the GPU host should stay off the public network entirely, terminate TLS on a separate gateway. A small scalable Linux VM is enough for nginx, and the GPU machine then only accepts connections from that one private address.

Activate and reload:

$ sudo ln -s /etc/nginx/sites-available/ollama.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl reload nginx
$ curl -u ollama-client:PASSWORD https://ollama.example.com/api/tags

Hardening checklist

The last row is worth acting on. If clients only need to run inference, deny the mutating endpoints in nginx with a dedicated location = /api/delete { deny all; } and the same for /api/pull and /api/create.

Troubleshooting

connection refused from a remote host. The service is still on loopback. ss -tlnp shows 127.0.0.1:11434 rather than *:11434. Re-check the drop-in, run sudo systemctl daemon-reload, and restart the service. A systemctl edit file that was saved without the [Service] header is silently ignored.

403 Forbidden only through the proxy. Ollama rejected the forwarded origin. Add proxy_set_header Host 127.0.0.1:11434; to the location block, or put the external hostname into OLLAMA_ORIGINS and restart the service.

Requests hang and then fail at 60 seconds. The proxy timed out mid-generation. Raise proxy_read_timeout and confirm proxy_buffering off is present, otherwise streaming responses arrive in one block at the end.

The firewall allows the port, but connections still fail. OLLAMA_HOST may point at a single interface that is not the one carrying the traffic. Compare the address in ss -tlnp with the interface in ip -brief addr.

Wrap-up

Changing the Ollama port is one line in a systemd drop-in. Everything that follows, the firewall scope, the reverse proxy and the blocked management endpoints, is what keeps an unauthenticated inference API from becoming a public one. Verify the bound address with ss -tlnp after every change, since a drop-in that never took effect looks identical to a working configuration until a client tries to connect.

Read next

• Calling the Ollama API from Your Own Applications
• Connecting Ollama to MCP Servers: Tools for Local Models
• Install Ollama on Ubuntu 24.04 and Run It as a Service
• Use a Local Coding Model with Ollama in Your IDE
• Managing Ollama Models: Updates, Cleanup and Disk Space
• Ollama vs LM Studio vs llama.cpp: Which Tool for What?
• Run Ollama in a Docker Container
• Set Up Open WebUI as a Front End for Ollama
• What Is Ollama? How It Works, Models and Use Cases