きっかけ

「WEBパフォーマンスチューニング ISUCON」という本を参考に、abコマンドを使ってlocalhostにアクセスしようとしたところ、WSL（Windows Subsystem for Linux）環境内からアクセスした際に問題が発生しました。具体的には、アクセスログにリクエストが記録されず、意図した動作が得られませんでした。試行錯誤の結果、解決策を見つけたので、共有します。

1. curlでlocalhostを叩いてみる

まず、問題の再現と原因を特定するために、curlを使ってlocalhostにアクセスしてみました。

WSL内からのアクセス

以下のコマンドでWSL内からlocalhostにアクセスした結果です。

curl -v localhost

出力は以下の通りです：

*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Tue, 13 Aug 2024 13:15:47 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Thu, 08 Aug 2024 05:17:10 GMT
< Connection: keep-alive
< ETag: "66b454d6-264"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

この結果から、localhostはWSL内で実行されているNginxサーバーのデフォルトページにアクセスしていることがわかります。

ホストのWindows側からのアクセス

次に、Windowsホスト側からlocalhostにアクセスした結果です：

curl -v localhost

出力は以下の通りです：

詳細: GET http://localhost/ with 0-byte payload
詳細: received 33313-byte response of content type text/html;charset=utf-8

StatusCode        : 200
StatusDescription : OK
Content           : <!DOCTYPE html>
                    <html>
                      <head>
                        <meta charset="utf-8">
                        <title>Iscogram</title>
                        <link href="/css/style.css" media="screen" rel="stylesheet" type="text/css">
                      </head>
                      <body>
                        <div clas...

ここでは、Windows側で実行されているWebサーバー（ISUCONサイト）にアクセスできていることが確認できます。

2. 問題の特定と解決策

問題

WSL内からlocalhostを叩くと、WSL内で実行されているサービスに接続されるため、Windowsホスト側で実行されているサービスにはアクセスできません。この違いは、WSLとWindowsホストが異なるネットワークスタックを持っているために発生します。

解決策

WSL内からWindowsホストで実行されているWebサーバーにアクセスするためには、localhostではなくhost.docker.internalという特別なドメイン名を使用します。このドメインは、Windowsホストを指し示し、WSL2やDockerコンテナからホスト側のサービスにアクセスする際に利用できます。

具体的には、以下のコマンドを使用します：

curl -v http://host.docker.internal/

これにより、WSL内からWindowsホスト上で実行されているサービスにアクセスでき、ホスト側のWebサーバーの応答を得ることができます。

3. 原因

この問題は、WSLとWindowsホストが異なるネットワークスタックを使用していることに起因しています。WSL2では、WindowsホストとWSL2インスタンスがそれぞれ独自のIPアドレスを持つため、localhostがWSL2インスタンス自身を指すようになり、ホスト側のサービスに直接アクセスできなくなります。

Microsoftが提供しているhost.docker.internalは、この問題を解決するための手段であり、WSL2からホスト側のサービスにアクセスするためのシンプルな方法です。

4. まとめ

WSL内からWindowsホストで動作しているサービスにアクセスする際には、localhostではなくhost.docker.internalを使用することで、ホスト側のサービスに正しくアクセスできます。これにより、WSL内での開発やテストがよりスムーズに行えるようになります。もし同様の問題に遭遇した場合、この手法を試してみてください。

記事を執筆するにあたり、生成AIを使用しました。