WSL2からWindowsのOllamaにつながらない時｜NAT・mirroredの確認順

最初にWindows側のAPIだけを確認する

この手順の対象は、Ollama serverがWindows本体で動き、接続するアプリがWSL2内で動く構成です。Ollama自体をWSL2内に入れた場合や、Docker containerから接続する場合は、確認するserverとネットワーク境界が変わります。

WindowsのPowerShellで次を実行します。/api/tagsは保存済みモデルの一覧を返すAPIなので、接続確認のためにモデルをダウンロードしたり、長い推論を始めたりする必要はありません。

Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/tags'

• WindowsでOllamaが起動しない時の確認 - Windows自身のAPIが返らない場合はこちらから直す

WSL2のネットワーク方式と接続方向を調べる

PowerShellでwsl --versionとwsl --list --verboseを実行し、WSLの版と対象distributionがWSL2かを記録します。wslinfoを含むWSLなら、WSL内で次のコマンドにより実行中のネットワーク方式を確認できます。

wslinfo --networking-mode

wslinfoが見つからない場合は、WSLの版とWindows側の.wslconfigを確認します。設定ファイルに書いた値は、再起動後に有効になった証拠とは別です。既定はNATですが、現行WSLには別方式やNAT失敗時のfallbackもあるため、実行中の方式とAPI応答を優先します。

• MicrosoftのWSL networking - 接続方向とNAT・mirroredの前提を確認する

mirroredではIPv4 localhostから試す

mirrored networkingが有効な構成では、WSL2からWindows serverへ127.0.0.1で接続できます。まずWSLのshellで次を試します。proxyを経由させず、接続と全体の待ち時間を区切った一回の確認です。

curl --noproxy '*' --connect-timeout 3 --max-time 10 http://127.0.0.1:11434/api/tags

ここでモデル一覧が返るなら、WSL2のアプリにも同じserverを設定します。Ollama native APIのbase URLはhttp://127.0.0.1:11434、OpenAI互換APIを使うクライアントでは通常末尾に/v1が必要です。アプリが求める形式を確認し、読み取りAPIの完全URLをそのままbase URL欄へ入れないでください。

127.0.0.1で成功してlocalhostだけ失敗する場合は、名前解決、IPv6、アプリのproxyを確認します。Microsoftのmirrored案内はIPv4 localhostを対象とし、IPv6 localhostの::1を同じ接続経路として扱っていません。

• OllamaのOpenAI互換API - base URLとモデルIDをアプリのAPI方式に合わせる

mirroredへ変える場合は設定場所と反映を確認する

Microsoftがmirroredを案内するのはWindows 11 22H2以降です。対応するWindows・WSLを使い、組織のVPNや管理方針で変更できることを確認した場合に検討します。Windows 10へ同じ設定だけを追加して解決するとは考えません。

1. Windowsユーザープロファイル直下の%UserProfile%\.wslconfigを確認する。既存ファイルがあれば先にcopyを残し、memoryやprocessors等の設定を消さない。
2. 既存の[wsl2]へnetworkingMode=mirroredを追加または修正する。WSL内の/etc/wsl.confへ書く設定ではない。
3. WSL内の作業を保存し、Docker Desktop等の関連アプリへの影響を確認する。再起動するまで設定は反映されない。
4. 必要な停止手順を選ぶ。wsl --shutdownは全distributionとWSL2 VMを直ちに終了するため、実行中の作業を残したまま使わない。
5. WSLを再起動し、実行中の方式と127.0.0.1:11434/api/tagsを再確認する。問題が増えた場合は保存した設定へ戻し、同じ反映手順で再確認する。

[wsl2]
networkingMode=mirrored

これは設定箇所を示す最小例です。既存.wslconfig全体をこの二行で上書きしないでください。mirroredを選ぶこと自体もネットワーク構成の変更なので、LAN到達性やFirewallの条件が変わっていないか併せて確認します。

• WSLの設定ファイルと反映条件 - .wslconfigとwsl.confの違いを確認する

NATを使う場合はWindows host IPと待ち受けを分ける

NATでWSL2からWindowsへつなぐときは、WSL内から見たWindows host IPを取得します。次はWSLのshellで行う接続確認です。IPを記事の固定値や以前のメモからコピーせず、その時点のrouteから調べます。

win_host=$(ip route show | awk '/default/ {print $3; exit}')
curl --noproxy '*' --connect-timeout 3 --max-time 10 "http://${win_host}:11434/api/tags"

Ollamaの既定の待ち受けは127.0.0.1:11434です。host IPを見つけただけでは、loopback限定のserverへNAT越しに接続できません。Windows側の待ち受けinterface、OLLAMA_HOSTが反映されたprocess、Windows Firewallの受信条件を順番に確認します。

NAT経由の接続が必要なら、下のLAN接続ガイドで公開範囲・接続元・port・戻し方を決めてからserver設定を変更します。0.0.0.0への変更やFirewall無効化を一律の復旧手順にせず、WSL2を使わずWindows側でclientも動かせる場合はその構成も選べます。

• Ollamaの待ち受けとWindows Firewallを確認する - NATでloopbackの外へ接続する必要がある場合の手順

方式を合わせても失敗する時の分岐

timeoutだけでFirewallが原因とは断定できません。一度にnetwork mode、server bind、proxy、portを変えず、Windows、WSLのshell、利用アプリの順で同じ読み取りAPIを確認します。モデル一覧が返った後に、短い非機密入力で目的のアプリを試してください。

• Open WebUIとWindows Ollamaの接続 - Docker containerのlocalhostとhost宛先を分ける
• OllamaのモデルIDを確認する - 接続成功後にモデル名やcapabilitiesを確認する
• ローカルAIの症状別トラブル解決ハブ - 生成やGPU利用の問題へ進む

復旧後に残す設定と確認結果

serverをWindowsに置く構成は、clientがWSL2にあっても推論をWSL2内へ移すものではありません。モデルの実行場所、local/cloudの選択、外部toolの通信は接続成功とは別に確認します。

1. Ollamaを起動する環境、接続するアプリの環境、WSL version、network mode、base URLを記録する。
2. WindowsとWSL2それぞれの/api/tagsの結果、利用するモデル名を保存する。共有時は内部IP、ユーザー名、個人情報を伏せる。
3. 変更した.wslconfig、OLLAMA_HOST、Firewall規則を見直し、不要な一時設定を戻す。
4. 次回の再起動でも同じ構成から接続できるか確認する。保存先やモデルを削除して接続問題を解決しようとしない。

• Ollamaのlocal modelとcloud model - 接続先と推論の実行場所を分けて確認する