Connecting to Ollama from Another Device on Your Network

Ollama becomes reachable from another device on your network only after you change two things: the address it binds to, and the path by which the other device reaches that address. Out of the box Ollama listens on 127.0.0.1:11434 — the loopback interface — so requests from your phone, laptop, or a home server never arrive. Setting OLLAMA_HOST=0.0.0.0, or turning on the equivalent option in the macOS and Windows app, fixes the first half. The second half is a decision, because Ollama’s API has no login: whatever can reach the port can use your models, pull new ones, and delete them.

This guide is written for a technically curious beginner or intermediate user who already runs Ollama on a machine at home or in a small office and wants to reach it from a second device. It covers the bind change, four exposure options ordered from narrowest to widest, verification commands that tell you which layer is broken, and the failure modes you are most likely to encounter.

Why the default configuration blocks other devices

Loopback is a network interface that only the local machine can address. A service bound to 127.0.0.1 is not merely firewalled off from the rest of the network — it is not listening on any interface that other machines can route to. That is why curl http://127.0.0.1:11434 succeeds on the host while the same request from your phone fails instantly with a connection error rather than a timeout.

Ollama ships this way because the API has no authentication layer. There is no username, no token, no session. That single fact drives almost every recommendation in this article: the bind address is the access control. A remote-access write-up checked on 12 October 2026 against the Ollama FAQ and Ollama’s server source puts it plainly — exposing the port lets every device on that network use your models, pull and delete them, and reach the endpoints affected by that year’s Ollama CVEs [2]. Treat any change to the bind address as a change to your security posture, not just a convenience setting.

Prerequisites

• A working Ollama installation on the host machine, confirmed by running a prompt locally.
• Permission to restart the Ollama server or app — environment variable changes require it.
• The host’s LAN address (for example 192.168.1.50), which you can read from the host’s network settings.
• A decision about who should be able to reach the server. Answer this before you open anything, because the four options below differ mainly in that answer.

Step 1: bind Ollama to an address other devices can reach

On Linux, the documented way to change the listening address is the OLLAMA_HOST environment variable, set when the server starts:

OLLAMA_HOST=0.0.0.0 ollama serve

0.0.0.0 means “every interface on this machine,” including any that might be reachable from outside your local network. If the host has a single LAN interface and no port forwarding, that is equivalent in practice to “this LAN only” — but it is worth confirming rather than assuming.

On macOS and Windows, the desktop app offers a simpler route: Settings → Expose Ollama to the network. The Ollama FAQ also documents configuring the server through environment variables, and notes that when Ollama runs as a macOS application those variables must be set with launchctl setenv (one call per variable) followed by a restart, because an app launched from Finder does not inherit your shell environment [1]. The app setting exists precisely so you do not have to do that by hand.

After changing either setting, restart Ollama completely. A running server keeps its original bind address until it is stopped and started again.

Step 2: verify on the host, then from the other device

Verification should proceed outward in layers, so that a failure tells you which layer is wrong.

On the host. Confirm the server is up and check which memory it loaded into with ollama ps [1]:

NAME        ID              SIZE    PROCESSOR       UNTIL
llama3:70b  bcfb190ca3a7    42 GB   100% GPU        4 minutes from now

The PROCESSOR column reports where the model was loaded: 100% GPU, 100% CPU, or a split such as 48%/52% CPU/GPU [1]. This matters later, because a model that fits comfortably at your desk may behave very differently when a second device starts a concurrent request.

From the second device. Ask the server to list its models:

curl http://192.168.1.50:11434/api/tags

A JSON list of installed models means the bind change worked and the network path is open. A refusal means the server is still on loopback or the port is blocked; a hang usually means the address is wrong or a firewall is dropping packets silently. The same pattern applies to generation requests, which the FAQ illustrates with the num_ctx option [1]:

curl http://192.168.1.50:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "options": { "num_ctx": 4096 }
}'

Step 3: choose the narrowest path that does the job

Binding to all interfaces is only one of several ways to connect. The options below are ordered from the least to the most exposure; pick the first row that matches your actual need rather than the most convenient one.

This framing comes from a remote-access guide that was checked against the Ollama FAQ, the Ollama server source, Tailscale’s Serve documentation, Open WebUI’s Tailscale page, and LM Studio’s server documentation in October 2026 [2].

Option A: an SSH tunnel

If you only need occasional access from a laptop you control, leave Ollama on 127.0.0.1:11434 on the host and forward the port over SSH:

ssh -N -L 11434:127.0.0.1:11434 you@gpu-box

While that command runs, http://127.0.0.1:11434 on the laptop is transparently routed to the host’s Ollama server [2]. No new port is opened, no firewall rule is added, and the tunnel exists only for the duration of the session. The tradeoff is that every client on the laptop must be pointed at 127.0.0.1, and the tunnel must be running.

Option D: LAN access with a firewall rule

For other machines on the same home network, the practical approach is to bind Ollama to the LAN address or to all interfaces and then restrict the port with the host firewall so that only your subnet can reach it. On Linux, a rule scoped to your subnet looks like this illustrative example:

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

Windows Firewall and macOS’s application firewall offer equivalent scoping through their graphical interfaces. The important property is that the rule names a source subnet rather than “any.” Remember that this option provides no login: every device on that subnet, including guests, can use and delete your models.

Options B and C: Tailscale

A tailnet is a private overlay network that only your enrolled devices can join. Putting Ollama on your tailnet (option C) gives API-speaking apps on other devices direct access without exposing anything to the LAN or the internet. Putting Open WebUI in front of it over Tailscale Serve (option B) adds a login layer, which suits phone-based chat where you do not want raw API access on the device.

Two things to avoid in this family of tools: do not use tailscale funnel, ngrok, or cloudflared against Ollama without the provider’s access control enabled, because all three publish the service to the internet; and do not forward port 11434 on your router [2].

Errors you are likely to see, and what each one means

“Connection refused” from the second device. The server is not listening on that address. Either the bind change did not take effect (restart required), or you are querying the wrong interface. Check with ollama ps that the server is running, then confirm the address you are using matches the host’s current LAN IP.

Requests hang and eventually time out. Something is dropping packets rather than rejecting them — typically a host firewall or an access point that isolates wireless clients from the wired network. Test from a device on the same subnet first to separate “firewall” from “network topology.”

A browser-based client fails with a CORS error while curl works. This is the most commonly misdiagnosed failure. OLLAMA_ORIGINS controls which websites are allowed to call the API from a browser; it does not control which devices can reach it [2]. Setting OLLAMA_ORIGINS=* to “make it work” widens browser access and leaves the actual device-level problem untouched.

Two operational details that surprise people

Context window. Ollama uses a context window of 4096 tokens by default, overridable with the OLLAMA_CONTEXT_LENGTH environment variable, with /set parameter num_ctx inside ollama run, or with the num_ctx field in an API request [1]. A remote client that does not set num_ctx silently gets the 4096 default, which can look like a quality regression when the real cause is truncation. Larger context also means a larger KV cache and more memory, so raising it affects what the host can keep loaded.

Concurrency. A server that runs comfortably for one user may not run comfortably for three. Because ollama ps reports the loaded size and processor split [1], it is the fastest way to see whether a second device’s requests pushed a model from GPU into system memory.

What to do next

If you have not opened anything yet, start with the SSH tunnel and confirm that a remote client can list models. That establishes that the server, the port, and the client configuration are all correct before you introduce a wider network path. Only then decide whether a tailnet or a scoped LAN rule is warranted — and if you do expose the port, re-check the firewall scope and confirm that port 11434 is not forwarded on your router.

Readers working through this in a home lab are welcome to share their setup in the community: the host operating system, the exposure option chosen, and the exact error text if something refused to connect. Concrete environments make these threads useful to the next person with the same symptom.