Ollama Port 11434: Expose the API Safely on Your Network

To make Ollama reachable from another device on your local network, set OLLAMA_HOST to 0.0.0.0:11434, restart Ollama, and allow port 11434 only from the network that should use it. Do not expose the raw Ollama port directly to the public internet. For remote access, put it behind a VPN or an authenticated HTTPS reverse proxy.

Quick Answer

This is the same trust-boundary decision that applies when choosing between local and remote MCP servers: decide who operates the service, who can reach it, and where credentials and data cross a network boundary.

Before You Change the Bind Address

Ollama listens on 127.0.0.1:11434 by default. Changing the address to 0.0.0.0:11434 makes it listen on every network interface, but your operating-system firewall and network router still determine which clients can connect.

Before continuing:

1. Identify the server's private IP address, such as 192.168.1.105.

2. Decide which subnet or specific devices should have access.

3. Keep the server and downloaded models patched.

4. Use a VPN or authenticated reverse proxy for any access beyond a trusted LAN.

Configure Ollama on macOS

When Ollama runs as the macOS application, set its environment variable with launchctl:

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Quit Ollama completely, then open it again. To return to local-only access later:

launchctl unsetenv OLLAMA_HOST

Restart Ollama after changing the value.

Configure Ollama on Linux

When Ollama runs as a systemd service, create a service override:

sudo systemctl edit ollama.service

Add only this override above the editor's discard marker:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Then reload the service configuration and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl status ollama

Confirm that the server is listening:

ss -ltnp | grep 11434

Configure Ollama on Windows

Ollama inherits Windows user and system environment variables:

1. Quit Ollama from the taskbar.

2. Open Edit environment variables for your account.

3. Create or update OLLAMA_HOST with the value 0.0.0.0:11434.

4. Save the change and start Ollama again.

If another device still cannot connect, check Windows Defender Firewall and confirm that the inbound rule is limited to the intended private network profile.

Test the Connection

First test from the Ollama server itself:

curl http://127.0.0.1:11434/api/tags

Then test from another device, replacing the address with the server's private IP:

curl http://192.168.1.105:11434/api/tags

Finally, test a generation request with a model you already installed:

curl http://192.168.1.105:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1",
    "prompt": "Why is the sky blue?",
    "stream": false
  }'

The Ollama API documentation lists the current endpoints and request formats.

Restrict Firewall Access

Avoid opening port 11434 to every source. On a Linux server using UFW, allow only your trusted LAN subnet:

sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp
sudo ufw status

Use your actual subnet. A narrower rule for one client IP is better when only one machine needs access.

Use a Safer Pattern for Internet Access

Direct router port forwarding sends public traffic straight to Ollama. A safer design is one of these:

• Private VPN: connect the client and server through Tailscale, WireGuard, or another private network and keep Ollama unavailable to the public internet.

• Authenticated reverse proxy: terminate HTTPS at Nginx, Caddy, Cloudflare Access, or another gateway that enforces identity before forwarding to 127.0.0.1:11434.

• Application backend: keep Ollama private and expose only the narrow operations your application needs, with authentication, input limits, timeouts, and rate limits.

If several people or agents share the service, also plan for model memory, concurrent requests, logs, and abuse limits. Network reachability is only one part of operating a reliable remote inference service.

Browser Clients and CORS

For a browser-based client on another origin, configure OLLAMA_ORIGINS with the exact trusted origin rather than a wildcard. The official Ollama FAQ documents this environment variable and proxy examples. CORS controls which browser origins may call the API; it does not replace authentication or firewall rules.

Troubleshooting

Connection refused

• Confirm Ollama is running.

• Confirm OLLAMA_HOST includes :11434.

• Check the listening socket with ss, netstat, or PowerShell.

• Test locally before testing from another device.

• Verify that the firewall rule matches the correct private subnet.

The local request works but the LAN request times out

The service is usually still bound to loopback, the host firewall is blocking the request, or the two devices cannot route to each other. Guest Wi-Fi and client-isolation settings commonly block device-to-device traffic.

A browser reports a CORS error

Add the exact web application's origin to OLLAMA_ORIGINS, restart Ollama, and confirm that the proxy preserves the expected Host header. Do not solve a CORS error by making the server publicly reachable.

The API returns 404

Test a documented endpoint such as /api/tags. A response from the server means the network path works; a 404 usually means the requested path is wrong rather than the port being unreachable.

Conclusion

For trusted local devices, bind Ollama to 0.0.0.0:11434, restrict the firewall, and test from both the host and a client. For remote users, keep the raw port private and add a VPN or authenticated HTTPS boundary. That gives you network access without turning a local model server into an unprotected public endpoint.

If you are connecting agents to shared SaaS and production tools rather than a local model server, Aident Loadout provides managed authentication, discovery, and audit for agent tool access.

Sources

• Ollama FAQ: server configuration and network exposure

• Ollama API introduction

• Local vs remote MCP servers