結論から書くと、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 address | 11434番を別のOllamaがもう使っている | 新しく起動せず、動いている方を使う |
| localhostだと約2秒遅れる・失敗する | localhostがIPv6の ::1 を先に試す | 接続先を127.0.0.1と書く |
| model not found(HTTP 404) | モデル名のタグ違い | ollama list の名前をそのまま書く |
| Dockerからだけ失敗する | コンテナのlocalhostはコンテナ自身 | host.docker.internal を使う(未確認) |
→ 関連: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-Listversion : 0.40.11こちらは動いているときの出力だけを確かめ、止まっているときの表示は試していません。
結果ごとに、次に見る場所
| 結果 | 分かること | 次に見る場所 |
|---|---|---|
| versionのJSONが返る | サーバーは動いている | 失敗するアプリの接続先・モデル名 |
| Could not connect to server | その番号で待ち受けているものが無い | 起動状態とポート |
| タイムアウト | 時間内につながらない | IPアドレス・経路・ファイアウォール |
| HTMLや別のJSONが返る | Ollama以外の何かが応答している | ポートの持ち主のプロセス |
ここで返っても、文章の生成まで通るとは限らないので、後半のモデル名の確認まで進めてください。
確かめた環境
- 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 0TIME_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, PathLocalAddress LocalPort OwningProcess
------------ --------- -------------
127.0.0.1 11434 16956
Id ProcessName Path
-- ----------- ----
16956 ollama C:\Users\<ユーザー名>\AppData\Local\Programs\Ollama\ollama.exeProcessName が ollama 以外なら、別のソフトが11434番を使っているので、そのソフトの設定を見るのが先です。
起動してすぐ止まるときはログを見る
ログの置き場所は、公式のトラブルシューティングに次のように書かれています。
| 環境 | ログの場所 |
|---|---|
| Windows | %LOCALAPPDATA%\Ollama の server.log(古いものは server-#.log) |
| macOS | ~/.ollama/logs/server.log |
| Linux(systemd) | journalctl -u ollama –no-pager –follow –pager-end |
| Docker | docker logs コンテナ名 |
| ollama serve を手で実行 | そのターミナルに出る |
当方の機の %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.1Ollamaの待ち受けは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 servemsg="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段階です。
- タスクバーのOllamaから終了する
- ユーザーの環境変数で OLLAMA_HOST などを作るか直す
- スタートメニューから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つずつ確かめると、設定を変えすぎずに済みます。
- 127.0.0.1:11434/api/version に返事があるかを見る
- 返事がなければ、アプリを起動するか ollama serve の「Listening on」の行でポートを確かめる
- 返事があるのにアプリだけ失敗するなら、接続先を127.0.0.1で書き、OLLAMA_HOST の値をそろえる
- つながったら、ollama list の名前(タグまで)でモデルを指定して生成を試す
つながったあとに使い方を広げるなら、次の記事が続きになります。
- 導入と基本の操作:Ollamaの使い方入門
- 一覧が空・Cドライブが足りない:Ollamaのモデル保存先を変える方法
- どのモデルを入れるか:ローカルLLMのおすすめモデル
- 生成中に落ちる:ローカルLLMのメモリ不足の切り分け
