KMMR Note

システムエンジニアの備忘録

  1. HOME
  2. 開発
  3. 仮想化・コンテナ
  4. WSLのWebアプリにWindowsから接続できない｜localhostとポートの確認順

WSLのWebアプリにWindowsから接続できない｜localhostとポートの確認順

WSLでWebアプリを起動したのに、Windowsのブラウザーではページが開かないことがあります。再インストールを考える前に、アプリが動いている場所、待ち受けているポート、Windowsからの接続を順に見ると、原因を絞りやすくなります。

ここではWindowsから同じPC上のWSL 2へ接続する場面を、小さなHTTPサーバーで確かめます。Linux側にPython 3.7以降・curl・ssが利用できる環境を用意してください。Pythonの簡易サーバーはローカル確認用に使い、作業用の一時フォルダーだけを配信します。

目次

起動している環境とURLを確認する

WindowsのPowerShellで、WSL本体の版と登録済み環境を表示します。

wsl --version
wsl --list --verbose

複数のUbuntuがある場合は、アプリを起動した環境の名前も確かめます。アプリの起動ログにあるポート番号と、ブラウザーへ入力したURLの番号が同じかも見てください。以下はhttp://127.0.0.1:8765/を使う例です。HTTPで起動したサーバーにHTTPSで接続するなど、方式が違っていてもページは開けません。

Linux側で確認用サーバーを起動する

WSLのLinux端末で、必要なコマンドが見つかることを確かめます。何も表示されないものがあれば、利用しているディストリビューションの方法で準備してから続けてください。

command -v python3
command -v curl
command -v ss

続けて同じ端末で次を実行します。mktemp -dで作る専用フォルダーに、表示を確かめるためのファイルを1枚置きます。

demo_dir=$(mktemp -d)
printf '%s\n' 'WSL localhost demo' > "$demo_dir/index.html"
python3 -m http.server 8765 --bind 127.0.0.1 --directory "$demo_dir"

この端末はサーバーの起動中、そのまま開いておきます。127.0.0.1へ明示的に待ち受けを限定した例です。すでに8765番が使われている場合は、空いている番号を選び、後続のURLと確認コマンドの番号も同じ値にしてください。

別のLinux端末で応答を確認する

同じディストリビューションの別の端末を開き、まずLinux内で応答するかを調べます。

curl --noproxy '*' --max-time 5 http://127.0.0.1:8765/
WSL localhost demo

この文字列が返れば、Linux側ではHTTPの応答が返っています。--noproxyは、この確認コマンドでプロキシを使わず直接つなぐ指定です。端末や組織全体のプロキシ設定を変更する操作ではありません。

応答しない場合は、待ち受けているポートも調べます。

ss -ltn '( sport = :8765 )'

サーバーが動いていれば、LISTENの行と127.0.0.1:8765が手掛かりになります。該当行がなければ、サーバー端末に戻って起動エラーや停止を調べます。ブラウザーやWindows側の設定を変える前に、この段階を通ると見直す場所を減らせます。

WindowsからTCP接続を確認する

Linux側で応答していることが分かったら、WindowsのPowerShellで確認します。

Test-NetConnection -ComputerName 127.0.0.1 -Port 8765 |
    Select-Object ComputerName, RemotePort, TcpTestSucceeded

TcpTestSucceededがTrueなら、指定したポートへTCP接続できています。これはWebページの内容やアプリの正常性まで保証する結果ではありません。結果の読み方は、Test-NetConnectionでTCP接続を確認する方法でも紹介しています。

HTTPの応答とブラウザー表示を確認する

(Invoke-WebRequest -Uri 'http://127.0.0.1:8765/' -UseBasicParsing -TimeoutSec 5).Content

Windows側でもWSL localhost demoが返ったら、ブラウザーでhttp://127.0.0.1:8765/を開きます。最初はlocalhostという名前を使わずIPv4のループバックでそろえると、名前の解決先の違いを切り離して調べられます。

確認用ページは開けるのに普段のアプリが開けないなら、アプリの起動環境、ポート、URL、HTTP/HTTPS、起動ログを見比べてください。確認用ページもWindowsから開けない場合は、WSLのネットワーク設定やセキュリティ製品、プロキシの適用条件が次の手掛かりになります。

接続先の方向と公開範囲を見直す

Microsoftの資料では、NAT構成のWSLでもWindowsからLinuxのアプリへlocalhostで接続できます。一方、LinuxからWindows側へ接続する場合や、別のPCからWSLへ接続する場合は条件が変わります。今回のWindowsから同じPC上のWSLへの確認と、接続の向きを取り違えないようにしてください。

Windows 11の対応環境にはmirrored方式もありますが、localhostが開けないことだけで、設定変更が必要だと決まるわけではありません。利用中の方式と対象バージョンを公式資料で確認し、まず上の順で起動と到達性を調べると判断しやすくなります。0.0.0.0への待ち受け変更は接続を受け付ける範囲が広がるため、同じ意味の置き換えとして一律に行わないでください。

確認用サーバーを停止する

確認が終わったら、サーバーを起動したLinux端末でCtrl+Cを押して停止します。今回作った一時フォルダーは、そのサーバー端末で保持しているdemo_dirの場所です。必要な結果を確認した後、検証用のファイルだけを片付けてください。アプリを停止した後に同じポートへつながらなくなるのは、停止した状態として確認する結果です。

参考資料