Amazonで商品を見るセール会場へ

Ollamaに接続できない原因と対処|11434番の確認から

Ollamaに接続できないとき

結論から書くと、Ollamaに接続できないときは、Ollamaを動かしているPCで curl.exe http://127.0.0.1:11434/api/version を実行し、返事があるかどうかで原因を2つに分けます。

返事がなければサーバーが止まっているかポートが違い、返事があるのに別のアプリだけ失敗するなら、アプリに書いた接続先が原因です。

Windows 11とOllama 0.40.11の実機で、わざと止めた・二重に起動した・ポートを変えたときの出力を載せています(2026年10月31日確認)。

DockerとWSLはこの機に無いので、公式資料の記載だけを未確認と分けて書きました。

症状原因対処
Could not connect to server(接続拒否)サーバーが止まっている/ポートが違うアプリを起動する、待ち受けポートを確かめる
Only one usage of each socket address11434番を別のOllamaがもう使っている新しく起動せず、動いている方を使う
localhostだと約2秒遅れる・失敗するlocalhostがIPv6の ::1 を先に試す接続先を127.0.0.1と書く
model not found(HTTP 404)モデル名のタグ違いollama list の名前をそのまま書く
Dockerからだけ失敗するコンテナのlocalhostはコンテナ自身host.docker.internal を使う(未確認)
実機で起こした症状と対処(Docker以外は2026年10月31日に確認)

→ 関連:Ollamaの使い方入門(導入から確かめ直すとき)

目次

結論:最初の1行で「止まっている」か「接続先が違う」かを分ける

Ollamaを動かしているPCでPowerShellを開き、次の1行を実行します。

curl.exe --noproxy "*" --connect-timeout 5 http://127.0.0.1:11434/api/version

動いていれば、当方の機では次の1行が返りました。

{"version":"0.40.11"}

Windows PowerShell 5.1では curl が Invoke-WebRequest の別名になっているので、curl.exe と拡張子まで書きます。

--noproxy "*" は、プロキシの設定を通らずに直接つなぐための指定です。

macOS・Linuxでは curl.exe を curl に変えて実行します。

curl.exe を使わずに PowerShell だけで見る

PowerShellのコマンドだけで確かめるなら、次の1行でも同じ答えが出ます。

Invoke-RestMethod http://127.0.0.1:11434/api/version | Format-List
version : 0.40.11

こちらは動いているときの出力だけを確かめ、止まっているときの表示は試していません。

結果ごとに、次に見る場所

結果分かること次に見る場所
versionのJSONが返るサーバーは動いている失敗するアプリの接続先・モデル名
Could not connect to serverその番号で待ち受けているものが無い起動状態とポート
タイムアウト時間内につながらないIPアドレス・経路・ファイアウォール
HTMLや別のJSONが返るOllama以外の何かが応答しているポートの持ち主のプロセス
/api/version の結果の読み方

ここで返っても、文章の生成まで通るとは限らないので、後半のモデル名の確認まで進めてください。

スポンサーリンク

確かめた環境

  • OS:Windows 11 Pro(10.0.26200)
  • Ollama:0.40.11(スタートメニューから起動するトレイのアプリ版)
  • PC:Ryzen 5 7530U・メモリ16GB・GPUなし
  • PowerShell:Windows PowerShell 5.1
  • 未導入:Docker、WSLのLinux(wsl –status はディストリビューション未導入と表示)
  • 確認日:2026年10月31日

出力に出たユーザー名入りのパスは、<ユーザー名>に置き換えて載せています。

止まっているとき:Could not connect to server と直し方

止めた状態で叩くと出るもの(実機)

トレイのOllamaとサーバーのプロセスを止めてから、同じ1行を実行しました。

curl: (7) Failed to connect to 127.0.0.1:11434 after 2041 ms: Could not connect to server

終了コードは7で、約2秒待ってから失敗しています。

待ち受けがあるかは、次のコマンドでも確かめることができます。

Get-NetTCPConnection -LocalPort 11434 -State Listen

止まっているときは、次のように「見つかりません」というエラーになりました。

一致する MSFT_NetTCPConnection オブジェクトが  CIM サーバー上の ROOT/StandardCimv2/MSFT_NetTCPConnection クラスのインスタンスの CIM クエリ: SELECT * FROM MSFT_NetTCPConnection  WHERE ((LocalPort = 11434)) AND ((State = 2)) で見つかりません。

netstat -ano では、止めた直後に TIME_WAIT の行だけが残り、LISTENING の行はありませんでした。

  TCP    127.0.0.1:61584        127.0.0.1:11434        TIME_WAIT       0
  TCP    127.0.0.1:61585        127.0.0.1:11434        TIME_WAIT       0

TIME_WAIT は終わった接続の後始末なので、この行があってもサーバーが動いていることにはなりません。

戻し方1:スタートメニューからOllamaを起動する

Windowsのアプリ版は、スタートメニューの「Ollama」を起動すると、トレイにアイコンが出てサーバーも立ち上がります。

起動から約8秒後に同じ1行を実行すると、versionのJSONが返りました。

当方の機では、止めた状態で ollama list を実行したところ、エラーにならずにトレイのアプリが自動で起動し、モデル一覧もそのまま出ました。

level=INFO source=app_windows.go:281 msg="starting Ollama" app=C:\Users\<ユーザー名>\AppData\Local\Programs\Ollama version=0.40.11 OS=Windows/10.0.26200
level=INFO source=app.go:253 msg="starting ollama server"
NAME           ID              SIZE      MODIFIED
gemma3:270m    e7d36fb2c3b3    291 MB    5 days ago
qwen3:8b       500a1f067a9f    5.2 GB    6 days ago

この自動起動は公式のWindowsの説明には書かれておらず、0.40.11の実機で見た動きです。

そのため、ターミナルの ollama list が通っても、ほかのアプリが接続した時点で動いていたとは限りません。

戻し方2:ollama serve で手動起動する

アプリを使わない構成では、ターミナルで ollama serve を実行します。

level=INFO source=routes.go:2516 msg="Listening on 127.0.0.1:11434 (version 0.40.11)"

この「Listening on」の行が、実際に待ち受けている住所とポートです。

このターミナルを閉じるとサーバーも止まるので、接続の確認は別のターミナルで行います。

Linuxでsystemdのサービスとして入れた場合は、systemctl status ollama で状態を見て、止まっていれば sudo systemctl start ollama で起動します(この機では未確認)。

Only one usage of each socket address は二重起動

トレイのアプリが動いている状態で、もう一つ ollama serve を実行すると、すぐに次のエラーで終わりました。

Error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

macOS・Linuxで「address already in use」と出るものと同じ意味で、Windowsでは文言がこうなります。

すでに動いているOllamaに接続できるなら、新しく起動する必要はありません。

11434番を使っているプロセスがOllamaかどうかは、次の2行で確かめます。

$c = Get-NetTCPConnection -LocalPort 11434 -State Listen
$c | Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id $c.OwningProcess | Select-Object Id, ProcessName, Path
LocalAddress LocalPort OwningProcess
------------ --------- -------------
127.0.0.1        11434         16956

   Id ProcessName Path
   -- ----------- ----
16956 ollama      C:\Users\<ユーザー名>\AppData\Local\Programs\Ollama\ollama.exe

ProcessName が ollama 以外なら、別のソフトが11434番を使っているので、そのソフトの設定を見るのが先です。

起動してすぐ止まるときはログを見る

ログの置き場所は、公式のトラブルシューティングに次のように書かれています。

環境ログの場所
Windows%LOCALAPPDATA%\Ollama の server.log(古いものは server-#.log)
macOS~/.ollama/logs/server.log
Linux(systemd)journalctl -u ollama –no-pager –follow –pager-end
Dockerdocker logs コンテナ名
ollama serve を手で実行そのターミナルに出る
公式のトラブルシューティングにあるログの場所(2026年10月31日確認)

当方の機の %LOCALAPPDATA%\Ollama には、app.log・server.log・server-1.log が並んでいました。

出典:Ollama 公式 Troubleshooting(2026年10月31日確認)

動いているのに失敗するとき:接続先の書き方を直す

localhost は約2秒遅れる(IPv6を先に試すため)

サーバーが動いている状態で、Pythonの標準ライブラリから3通りの書き方で /api/version を呼びました。

http://127.0.0.1:11434/api/version -> {'version': '0.40.11'} (0.08s)
http://localhost:11434/api/version -> {'version': '0.40.11'} (2.04s)
http://[::1]:11434/api/version -> URLError: [WinError 10061] 対象のコンピューターによって拒否されたため、接続できませんでした。 (2.05s)

127.0.0.1は0.08秒で返ったのに、localhostは2.04秒かかりました。

curl.exe -v で見ると、localhostはまずIPv6の [::1] を試し、断られてから127.0.0.1につないでいます。

* Host localhost:11434 was resolved.
*   Trying [::1]:11434...
*   Trying 127.0.0.1:11434...
> GET /api/version HTTP/1.1

Ollamaの待ち受けは127.0.0.1だけで、[::1] には誰もいないためです。

IPv6だけを試す設定では、curl.exe -6 と同じように失敗します。

curl: (7) Failed to connect to localhost:11434 after 2043 ms: Could not connect to server

アプリの接続先には、localhostではなく http://127.0.0.1:11434 と数字で書くのがいちばん確実です。

OLLAMA_HOST のポートがずれると、サーバーが2つになる

そのターミナルだけ OLLAMA_HOST を127.0.0.1:11500にして ollama serve を起動し、ポートのずれを起こしました。

$env:OLLAMA_HOST = '127.0.0.1:11500'
ollama serve
msg="Listening on 127.0.0.1:11500 (version 0.40.11)"

このとき、11434番を指すアプリは接続拒否で、11500番なら返る状態です。

> curl.exe --connect-timeout 5 http://127.0.0.1:11434/api/version
curl: (7) Failed to connect to 127.0.0.1:11434 after 2046 ms: Could not connect to server
> curl.exe http://127.0.0.1:11500/api/version
{"version":"0.40.11"}

同じターミナルの ollama list は OLLAMA_HOST を読むので、11500番のサーバーに問題なくつながりました。

ところが、OLLAMA_HOST を消した別の状態で ollama list を実行すると、トレイのアプリが自動で起動し、11434番にもう一つサーバーが立ちました。

LocalAddress LocalPort OwningProcess
------------ --------- -------------
127.0.0.1        11500         20100
127.0.0.1        11434         38420

こうなると、ターミナルとアプリでは別のサーバーを見ることになり、設定したはずのモデルや保存先が見えないという症状に変わります。

ポートを変えたら、サーバー側とアプリ側の両方を同じ値にし、Get-NetTCPConnection -State Listen で待ち受けが1つだけかを確かめます。

モデル一覧が空になる場合は保存先の違いも疑えるので、Ollamaのモデル保存先を変える方法も見てください。

つながるのに生成できない:モデル名の404

タグを付けずに gemma3 と送ると、接続はできても次のエラーが返りました。

{"error":"model 'gemma3' not found"}
HTTP 404

手元にあるのは gemma3:270m などタグ付きの名前なので、ollama list に出た名前をそのまま書きます。

gemma3:270m と正しく書くと HTTP 200 で答えが返り、全体で3.3秒のうち2.88秒はモデルの読み込みでした。

URLの書き間違いでも404になりますが、そのときは 404 page not found という素の文字列で、モデル名の404とは中身が違います。

生成を始めてから落ちる場合は、ローカルLLMのメモリ不足の切り分けに進んでください。

Dockerからだけつながらないとき(この機では未確認)

ここから先は、この機にDockerが無いため、公式資料の記載だけをまとめています。

コンテナの中のlocalhostはコンテナ自身を指すので、ホストのOllamaを http://localhost:11434 と書いても届きません。

Open WebUIの公式手順は、Ollamaがホストで動いているなら http://host.docker.internal:11434 を使うよう案内しています。

設定する場所は、Open WebUIの管理者設定の「Connections」にあるOllamaの接続の欄です。

出典:Open WebUI 公式 Starting with Ollama(2026年10月31日確認)

Ollamaのほうもコンテナで動かすなら、公式の例は -p 11434:11434 でポートをホストに出しています。

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

出典:Ollama 公式 Docker(2026年10月31日確認)

ホストのOllamaとコンテナのOllamaを同時に動かすと、上のポートずれと同じく、モデル一覧の違う2つのサーバーを見比べることになります。

ホスト側が127.0.0.1だけで待ち受けているときにコンテナから届くかは、Dockerの構成で変わり、この記事では確かめていません。

WSLからだけつながらないとき(この機では未確認)

この機にはWSLのLinuxが入っていないため、Microsoftの資料の記載だけをまとめます。

WSL2の既定のNAT構成では、Linuxから見たWindowsは別の住所なので、Windowsで通ったURLをそのまま使っても届きません。

WindowsのIPアドレスは、WSLの中で次のコマンドを実行すると分かります。

ip route show | grep -i default | awk '{ print $3}'

この住所からの接続はLANからの接続として扱われるので、Ollamaの待ち受けを127.0.0.1から広げなければなりません。

Windows 11 22H2以降でミラーモードを有効にすると、WSLからWindowsのサーバーへ127.0.0.1で接続できます。

ただし資料には、IPv6の ::1 は使えないと書かれているので、ここでもlocalhostではなく127.0.0.1と書くのが無難です。

出典:Microsoft Learn「Accessing network applications with WSL」(2026年10月31日確認)

OLLAMA_HOST・OLLAMA_ORIGINS・プロキシを変えるときの注意

公式FAQには、Ollamaは既定で127.0.0.1の11434番で待ち受け、変えるときは環境変数 OLLAMA_HOST を使うと書かれています。

Windowsで環境変数を変えるときの手順は、FAQでは次の3段階です。

  1. タスクバーのOllamaから終了する
  2. ユーザーの環境変数で OLLAMA_HOST などを作るか直す
  3. スタートメニューからOllamaを起動し直す

起動し直さないと古い値のまま動くので、変えたのに直らないときは、まずアプリを終了しているかを見ます。

0.0.0.0にすると同じネットワークのほかの機器からも接続できるようになるため、必要なときだけ変え、ファイアウォールで接続元を絞ります。

この記事では、ほかの機器へ公開する設定(0.0.0.0)とファイアウォールの許可は試していません。

ブラウザーの拡張機能やWebページから呼ぶときは、通信は届いていても、OLLAMA_ORIGINS で許可していない接続元をOllamaが断ります。

curlで通るのに、ブラウザーの開発者ツールにだけCORSのエラーが出るなら、この設定が原因の候補です。

もう一つの落とし穴はプロキシで、FAQは HTTP_PROXY を設定するとクライアントとサーバーの接続が途切れることがあるとして、使わないよう書いています。

モデルのダウンロードにプロキシが要るなら、HTTPS_PROXY のほうを使います。

出典:Ollama 公式FAQ(2026年10月31日確認)、Ollama 公式 Windows(2026年10月31日確認)

スポンサーリンク

まとめと次にやること

接続できないときは、次の順で1つずつ確かめると、設定を変えすぎずに済みます。

  1. 127.0.0.1:11434/api/version に返事があるかを見る
  2. 返事がなければ、アプリを起動するか ollama serve の「Listening on」の行でポートを確かめる
  3. 返事があるのにアプリだけ失敗するなら、接続先を127.0.0.1で書き、OLLAMA_HOST の値をそろえる
  4. つながったら、ollama list の名前(タグまで)でモデルを指定して生成を試す

つながったあとに使い方を広げるなら、次の記事が続きになります。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

須澤 元貴のアバター 須澤 元貴 代表社員

MOTOKI合同会社 代表社員。
アニメ・映像業界とゲーム業界で、2D・UI・3D・アニメーション制作、映像編集、ツール制作に携わってきました。
現在はWordPressを中心にWebサイトの制作とカスタマイズを手がけています。
著書に『Unity デザイナーズ・バイブル』『Unityゲーム プログラミング・バイブル 2nd Generation』(ボーンデジタル)。
岡山県出身、埼玉県在住。

次に学ぶ・作業環境を選ぶ

学習を続けたい方や、作業環境を整えたい方は、目的に合うガイドをご覧ください。

生成AIのおすすめ書籍

周辺機器の優先度

目次