Docker の Open WebUI や n8n が Ollama に接続できない

Munim, Inc. の MV2 による。2026 年 10 月 12 日に Open WebUI と n8n のドキュメント、および Ollama のソースコードと照合済み。このページは英語の原文から AI で翻訳したものです。内容に食い違いがある場合は原文が優先します。

よくあるエラー: Open WebUI に「Ollama: Network Problem」や「Server Connection Error」と表示される、またはログに Connect call failed ('127.0.0.1', 11434) と出る。n8n の Ollama 認証情報のテストが ECONNREFUSED 127.0.0.1:11434 や ECONNREFUSED ::1:11434 で失敗する。Dify、Flowise、AnythingLLM でも同様の「connection refused」エラーが出ます。

原因: コンテナの中では、localhost や 127.0.0.1 はあなたのコンピューターではなく、そのコンテナ自身を指します。Ollama は既定でホストの 127.0.0.1:11434 で待ち受けているため、http://localhost:11434 を使うコンテナは違う家のドアを叩いていることになります。

多くのガイドが勧める手早い対処は OLLAMA_HOST=0.0.0.0 です。これで動きますが、ログインのない Ollama をネットワーク上のすべての端末に開くことにもなります。まずは以下の方法を試してください。

まずテスト: コマンド 1 つ

ホストで Ollama が動いているか確認します: curl http://127.0.0.1:11434/api/version。次に、アプリが使うアドレスを使い捨てのコンテナの中からテストします:

docker run --rm --add-host=host.docker.internal:host-gateway curlimages/curl -s http://host.docker.internal:11434/api/version

{"version":"0.x.y"} のような応答が返れば、その URL はコンテナから使えます。「Connection refused」やタイムアウトなら使えません。ご自身の構成に合わせて先を読んでください。Open WebUI のイメージには curl が入っているので、docker exec open-webui curl -s http://host.docker.internal:11434/api/version でも試せます。

構成ごとの対処法

あなたの構成	アプリに設定するベース URL	備考
Docker Desktop（Mac または Windows）、Ollama アプリはホスト上	`http://host.docker.internal:11434`	そのまま動きます。Ollama は 127.0.0.1 のままで構いません。対処法 1。
Linux、Ollama はホストにインストール、アプリは Docker	`http://host.docker.internal:11434` と `--add-host`	Ollama がコンテナから届く場所でも待ち受ける必要があります。対処法 2 または 3。
Ollama とアプリが同じ Compose ファイル	`http://ollama:11434`（サービス名）	最善の方法です。Ollama にポートの公開は不要です。対処法 4。
Ollama は Docker、アプリはホストにインストール（たとえば npm で入れた n8n）	`http://127.0.0.1:11434`	`-p 127.0.0.1:11434:11434` で公開します。`::1` のエラーを避けるため、localhost ではなく 127.0.0.1 を使います。

対処法 1: Docker Desktop（Mac、Windows）

Docker Desktop はすべてのコンテナに host.docker.internal を用意し、あなたのコンピューターへ転送します。そこでアプリの Ollama の URL を http://host.docker.internal:11434 に設定します。Open WebUI では環境変数 OLLAMA_BASE_URL（または「Admin Settings」→「Connections」）です。n8n では Ollama 認証情報の「Base URL」を編集します。Ollama 側の OLLAMA_HOST を変える必要はありません。

docker run -d -p 127.0.0.1:3000:8080 --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

127.0.0.1:3000 にすると、Open WebUI はこのコンピューターからしか開けません。-p 3000:8080 はほかの端末から開く必要がある場合にだけ使い、その場合は誰でも登録できる状態をオフにしてください。ネットワークに開かずにスマートフォンから使うには、Tailscale Serve 経由の Open WebUI を参照してください。

対処法 2: Linux で最も簡単で安全な方法: アプリにホストネットワークを使う

Linux では --network=host を付けるとコンテナがホストのネットワーク上で動くため、127.0.0.1:11434 が本当にホストの Ollama を指し、Ollama は localhost にバインドしたままで済みます。Open WebUI のドキュメントにもある方法です。ポートが 8080 になる点に注意してください:

docker run -d --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

http://localhost:8080 を開きます。ホストネットワークでは Open WebUI は通常のプログラムと同じくポート 8080 で待ち受けるので、この場合はホストのファイアウォール（ufw、firewalld）がちゃんと効きます。8080 は必要な接続元からだけ許可してください。

対処法 3: Linux で host.docker.internal を使い、Ollama にはコンテナからだけ届くようにする

Linux では --add-host=host.docker.internal:host-gateway（Compose では extra_hosts: ["host.docker.internal:host-gateway"]）で、その名前が Docker ブリッジのアドレス（通常は 172.17.0.1）を指すようになります。127.0.0.1 の Ollama はそこでは待ち受けていないので、より広く待ち受けさせたうえで、コンテナ以外はファイアウォールで締め出す必要があります:

Ollama をすべてのインターフェースで待ち受けさせます: sudo systemctl edit ollama.service で次を追加し、
```
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
```
その後 sudo systemctl daemon-reload && sudo systemctl restart ollama を実行します。
Docker のネットワークだけを許可し、残りをブロックします（ufw の例。Docker の既定のネットワークは 172.16.0.0/12 の範囲にあります）:
```
sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp
sudo ufw deny 11434/tcp
```
順序が重要です。allow ルールが先に来る必要があります（順序は sudo ufw status numbered で確認できます）。ufw が既定の「deny incoming」で有効になっている場合、コンテナを通すのはこの allow ルールだけです。ブロックされたコンテナには、たいてい「refused」ではなくタイムアウトが返ります。
ネットワーク上の別の端末から curl http://<this machine's LAN IP>:11434/api/version（このマシンの LAN 内 IP に置き換えます）を実行すると、今度は失敗するはずです。一方、上の使い捨てコンテナのテストは成功します。

docker -p で公開したポートは ufw を素通りしますが、ホストにインストールした Ollama は通常のプログラムなので、これらの ufw ルールが効きます。

対処法 4: Ollama を同じ Compose ファイルに入れる

同じ Compose ネットワーク上のコンテナはサービス名で互いに届くので、Ollama にポートの公開は不要で、Docker の外からは届きません:

services:
  ollama:
    image: ollama/ollama
    volumes: [ "ollama:/root/.ollama" ]
    # no "ports:" - only containers on this network can reach it
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    ports: [ "127.0.0.1:3000:8080" ]
    volumes: [ "open-webui:/app/backend/data" ]
volumes:
  ollama: {}
  open-webui: {}

（ファイル内のコメントは「ports: は書かない。このネットワーク上のコンテナだけが届く」という意味です。）同じファイルに入れた n8n、Dify、Flowise、AnythingLLM も http://ollama:11434 を使います。GPU を使うには、Ollama の Docker ドキュメントにあるデバイス予約の設定を ollama サービスに追加します。アプリが別の Compose プロジェクトで動いている場合は、両方を 1 つの共有の外部ネットワークに接続します。

それでも失敗する場合

ホスト上の n8n で ECONNREFUSED ::1:11434: localhost が IPv6 に解決され、Ollama は IPv4 で待ち受けています。n8n のドキュメントでは localhost の代わりに 127.0.0.1 を使うよう勧めています。
Podman: ホスト名は host.containers.internal です。
「refused」ではなく「403 Forbidden」: これはネットワークの問題ではありません。Ollama が応答したうえで拒否しています。よくある原因は 2 つです。(1) Web ページやブラウザ拡張機能が Ollama を呼び出していて、OLLAMA_ORIGINS がそれをブロックしている。ブラウザチェック（英語）を参照してください。Open WebUI、n8n、Dify は自分のサーバーから Ollama を呼ぶので、OLLAMA_ORIGINS は不要です。(2) リバースプロキシやトンネルが、127.0.0.1 で待ち受ける Ollama に自分のホスト名を渡している。このモードの Ollama は localhost 系の Host 名しか受け付けません。host.docker.internal が通るのはそのためです（.internal で終わるため）。Ollama FAQ の例と同じく、プロキシから Host: localhost:11434 を送らせてください。Tailscale Serve も同じチェックに引っかかります。tailscale serve が 403 を返す理由を参照してください。
動くが遅い: Ollama slow or not using the GPU（英語）を参照してください。

接続できたら、意図した以上に開けていないかを確認してください。無料のスクリプト local-ai-checkup（読み取り専用で、マシンの外には何も送信しません）を実行すると、Ollama のバインドアドレス、公開されている Docker ポート、バージョンがわかります。Ollama が外部に公開されていないか？もあわせてご覧ください。

代わりに確認してほしい場合

Munim, Inc. の MV2 は、マシン 1 台のローカル AI ヘルスチェック（49 米ドル）と、最大 5 台または共有の Ollama・Open WebUI・n8n サーバー 1 台を対象にした小規模オフィス向けチェック（199 米ドル）を提供しています。何が公開されていて、何が危険または遅いのか、何から直すべきかをまとめた報告書を、お使いの OS 向けの正確なコマンドとともにお届けします。報告書は英語です。報告書のサンプル（英語）をご覧ください。Stripe で 49 ドルを支払うか 199 ドルを支払うと、その後 munimversion2@gmail.com へ、python3 local_ai_checkup.py --json の出力、お使いの OS、用途をメールで送ってください。MV2 がパスワード、キー、リモートアクセスを求めることはありません。