【備忘録】Docker＋Laravel＋Viteで同じ環境なのに片方だけdev サーバーに繋がらない問題を完全解決した方法【WSL2／0.0.0.0／localhost】

2025年11月26日

★環境
　ベースOS：Windows11
　仮想：WSL2
※開発環境PCが2台(PC_Aと PC_B)

概要

現象
同一リポジトリ・同一 Docker 構成の Laravel + Vite プロジェクトで、
- PC_A では docker compose up -d → npm run dev で問題なく開発できる
- PC_B では同じ手順なのにブラウザで Vite 関連のエラーが発生する
原因（要約）
- PC_B の Windows ↔ WSL のポート転送（localhost 転送）が不安定／無効
- さらに Vite を --host 0.0.0.0 で起動したことで、Laravel が dev サーバ URL を http://0.0.0.0:5174 と認識してしまった
最終的な解決
1. Windows 側で portproxy を設定し、127.0.0.1:5174 → WSL_IP:5174 を転送
2. vite.config.js に server.hmr.host = '127.0.0.1' を設定し、Laravel の @vite が必ず http://127.0.0.1:5174 を出すようにした
3. package.json の "dev" スクリプトを vite --host 0.0.0.0 --port 5174 に変更し、両 PC とも npm run dev だけで統一

環境

OS：Windows 11
開発用仮想環境：WSL2（例：Ubuntu-20.04）
Docker：Docker Desktop + docker compose
フレームワーク：Laravel 11.x
フロント：Vite 5.x, Node.js 20.x 系
アプリ URL：http://app-dev.test
Vite dev サーバ（期待値）：http://127.0.0.1:5173 〜 5174

発生した現象の詳細

1. PC_A（正常な方）

PC_A では以下の手順で問題なく動作していた：

docker compose up -d
npm run dev

Vite のログ（一部）：

Port 5173 is in use, trying another one...

VITE v5.3.x ready

➜  Local:   http://localhost:5174/
➜  APP_URL: http://app-dev.test

ブラウザで http://app-dev.test を開くと、HTML の <head> に以下のタグが入る：

&lt;script type="module" src="http://127.0.0.1:5174/@vite/client"&gt;&lt;/script&gt;
&lt;link rel="stylesheet" href="http://127.0.0.1:5174/resources/css/app.css"&gt;
&lt;script type="module" src="http://127.0.0.1:5174/resources/js/app.js"&gt;&lt;/script&gt;

開発者ツール上のエラー：なし
http://127.0.0.1:5174/@vite/client もブラウザからアクセス可能

2. PC_B（問題が出た方）

同じリポジトリを clone し、同じ手順で起動：

docker compose up -d
npm run dev

最初のエラー：`ERR_CONNECTION_RESET`

ブラウザコンソール：

GET http://127.0.0.1:5174/@vite/client net::ERR_CONNECTION_RESET
GET http://127.0.0.1:5174/resources/css/app.css net::ERR_CONNECTION_RESET
GET http://127.0.0.1:5174/resources/js/app.js net::ERR_CONNECTION_RESET

WSL 内での確認：

curl http://127.0.0.1:5174/@vite/client   # → 正常にレスポンスが返る

しかし Windows 側ブラウザから http://127.0.0.1:5174 へアクセスすると失敗。

つまり：

「WSL 内の Vite は動いているが、Windows → WSL2 の localhost 転送が壊れている」 状態だった。

試したこと（失敗＆遠回り含む）

1. `.env` の比較・調整（結果：原因ではなかった）

PC_A と PC_B の .env を比較
Laravel Passport や SESSION 周りなどの差分はあったが、Vite やポートに関する差分はコメントアウトされており無効
.env を揃えても現象は変わらず

⇒ DB や SESSION の差分が原因ではない と判断。

2. `.wslconfig` で `localhostForwarding=true`（効果なし）

Windows 側で以下のファイルを作成：

C:\Users\&lt;USER&gt;\.wslconfig

中身：

[wsl2]
localhostForwarding=true

wsl --shutdown → WSL 再起動後も症状は変わらず。

wsl -l -v では VERSION=2 になっており、WSL2 自体は正常だった。

⇒ .wslconfig だけでは回復しないケース だった。

3. Vite に `--host 0.0.0.0` を付ける（途中までは正解）

目的： WSL 内で 0.0.0.0 にバインドさせ、172.x.x.x の WSL IP 経由や portproxy でアクセスしやすくするため。

一時的に起動コマンドを変更：

npm run dev -- --host 0.0.0.0 --port 5174

ログ：

Local:   http://localhost:5174/
Network: http://10.255.255.254:5174/
Network: http://172.17.xxx.xxx:5174/

この状態で：

WSL 内：curl http://127.0.0.1:5174/ → OK
Windows：http://<WSL_IP>:5174/ → OK
Windows：Test-NetConnection 127.0.0.1 -Port 5174 → portproxy 設定後は OK

と、「Vite 本体へのネットワーク到達」はほぼ解消された。

しかし、この直後に新たなエラーが発生。

新たなエラー：`0.0.0.0:5174` への `ERR_ADDRESS_INVALID`

ブラウザコンソール：

GET http://0.0.0.0:5174/@vite/client net::ERR_ADDRESS_INVALID
GET http://0.0.0.0:5174/resources/css/app.css net::ERR_ADDRESS_INVALID
GET http://0.0.0.0:5174/resources/js/app.js net::ERR_ADDRESS_INVALID

PC_B の <head> 抜粋：

&lt;script type="module" src="http://0.0.0.0:5174/@vite/client"&gt;&lt;/script&gt;
&lt;link rel="stylesheet" href="http://0.0.0.0:5174/resources/css/app.css"&gt;
&lt;script type="module" src="http://0.0.0.0:5174/resources/js/app.js"&gt;&lt;/script&gt;

Laravel が dev サーバを 0.0.0.0:5174 と認識して、そのまま書き出してしまっていた。

0.0.0.0 は「全てのインターフェースで待ち受ける」ためのサーバ側の記号であり、
クライアントからの URL としては無効なため ERR_ADDRESS_INVALID となる。

4. `.env` に `VITE_DEV_SERVER_URL` を書いてみる（効かなかった）

PC_B の .env に以下を追加：

VITE_DEV_SERVER_URL=http://localhost:5174

期待：

@vite がこの URL を見て localhost:5174 を使ってくれるかも？

結果：

Laravel 11 標準の設定ではこの env を見ておらず、出力される URL は依然として http://0.0.0.0:5174/... のまま。

⇒ この方法では dev サーバ URL を上書きできなかった。

最終的な解決策

最終的には、

Windows ↔ WSL の経路を portproxy で確保
Laravel が使う dev サーバの「ホスト名」を Vite 設定で固定
npm run dev を両 PC で統一

という 3 本立てで解決した。

1. Windows 側 portproxy の設定（PC_Bのみ）

1-1. WSL の IP を確認

powershell
wsl -d Ubuntu-20.04 hostname -I
# → 例: 172.17.212.109

1-2. 管理者 PowerShell で portproxy を追加

netsh interface portproxy add v4tov4 ^
  listenaddress=127.0.0.1 listenport=5174 ^
  connectaddress=172.17.212.109 connectport=5174

※ connectaddress は実際の WSL IP に置き換え。

これにより、Windows の 127.0.0.1:5174 へのアクセスが
WSL 内の 172.17.212.109:5174 に転送される。

1-3. 接続確認

Test-NetConnection 127.0.0.1 -Port 5174
# → TcpTestSucceeded : True

この状態で http://localhost:5174 もブラウザからアクセス可能になる。

注意： WSL の IP (172.x.x.x) は再起動などで変わることがあるため、変わった場合は portproxy の削除＆再設定が必要。

2. Vite 設定で `@vite` が使うホスト名を固定

vite.config.js（リポジトリ共通・PC_A/PC_B 両方で使用）に
最小限の追記を行った。

2-1. 変更後の `vite.config.js`（イメージ）

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: ['resources/css/app.css', 'resources/js/app.js'],
            refresh: true,
        }),
    ],
    server: {
        hmr: {
            host: '127.0.0.1',  // ← ポイント
        },
    },
});

server.host はいじらず、hmr.host のみ 127.0.0.1 に固定
これにより、dev サーバ URL のホスト名として常に 127.0.0.1 が使われる

この変更により、PC_B の <head> も PC_A と同じ：

&lt;script type="module" src="http://127.0.0.1:5174/@vite/client"&gt;&lt;/script&gt;
&lt;link rel="stylesheet" href="http://127.0.0.1:5174/resources/css/app.css"&gt;
&lt;script type="module" src="http://127.0.0.1:5174/resources/js/app.js"&gt;&lt;/script&gt;

という形に揃った。

3. `npm run dev` を両 PC で共通化する

それまでは一時的に PC_B だけ：

npm run dev -- --host 0.0.0.0 --port 5174

を使っていたが、PC ごとにコマンドを変えるのは運用上わかりづらい。
そこで package.json の "dev" スクリプトにオプションを組み込んだ。

3-1. `package.json` の scripts

"scripts": {
  "dev": "vite --host 0.0.0.0 --port 5174",
  "build": "vite build",
  "preview": "vite preview"
}

これにより、PC_A/PC_B 両方とも：

npm run dev

だけで Vite が 0.0.0.0:5174 で待ち受けるようになった。

一方、vite.config.js の hmr.host = '127.0.0.1' により、
@vite は常に 127.0.0.1 を使うので、

PC_A：元々正常だった localhost 転送で到達
PC_B：portproxy のおかげで到達

という形でどちらも問題なく動作するようになった。

本番運用への影響について

本番環境では Docker/WSL を使っていない
本番には npm run build でビルドしたファイルをデプロイ
npm run build では server や hmr の設定は参照されず、
純粋に build 設定＋ manifest ベースの出力のみ行う

したがって、

vite.config.js の server.hmr.host
package.json の "dev" スクリプト
Windows の portproxy や .wslconfig

はいずれも 開発環境専用の設定 であり、
本番環境には基本的に影響しない。

PC_A/PC_B のどちらのマシンから npm run build しても、依存バージョン・Node バージョンを揃えておけば、
生成物はほぼ同等と考えてよい。

同様の問題に遭遇した人向けチェックリスト

ブラウザエラーを確認
- 127.0.0.1:5173/5174 に対する ERR_CONNECTION_RESET？
- 0.0.0.0:5173/5174 に対する ERR_ADDRESS_INVALID？
WSL 内から Vite にアクセスできるか？
curl http://127.0.0.1:5174/ ここで OK なら「Vite 自体は動いている」。
Windows から Vite に直接アクセスできるか？
- wsl -d <DistroName> hostname -I で WSL IP を取得
- その IP で http://<WSL_IP>:5174/ にアクセス
Windows ↔ WSL の localhost 転送を疑う
- .wslconfig の localhostForwarding=true で改善するか？
- ダメなら netsh interface portproxy で 127.0.0.1:5174 → <WSL_IP>:5174 を張ることも検討。
@vite が出力する URL を確認
- view-source:http://app-dev.test などで <head> 内の script/link を確認
- http://0.0.0.0:5174/... になっていたら vite.config.js の server.hmr.host などでホスト名を固定する。
PC ごとの差分はなるべく npm run dev の中に閉じる
- package.json の "dev" スクリプトを統一
- それでも差が出る場合は .env や Windows 設定側に寄せて、ソースコードに PC 分岐を書かない

まとめ

同じ Docker / Laravel / Vite プロジェクトでも、
Windows/WSL のネットワーク挙動の差によって、

片方の PC だけ npm run dev が正常に使えない

という状況が起こり得る。

特に、

WSL2 の localhost 転送
Vite の --host 0.0.0.0
laravel-vite-plugin が dev サーバ URL をどう決めるか

が組み合わさると、

「127.0.0.1 で繋がらないと思ったら、今度は 0.0.0.0 に飛んでエラーになる」
という、一見理不尽な挙動に見える状態になりやすい。

今回の解決パターンは：

ネットワーク到達（portproxy）をまず直す
Laravel が使う dev サーバ URL（ホスト名）を Vite 設定で固定
npm run dev を共通の形に揃えて運用をシンプルにする

という手順で、

「PC どちらでも、docker compose up -d → npm run dev のワンパターンで開発できる」
状態まで持っていくことができた。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

【備忘録】Docker＋Laravel＋Viteで同じ環境なのに片方だけdev サーバーに繋がらない問題を完全解決した方法【WSL2／0.0.0.0／localhost】

概要

環境

発生した現象の詳細

1. PC_A（正常な方）

2. PC_B（問題が出た方）

最初のエラー：ERR_CONNECTION_RESET

試したこと（失敗＆遠回り含む）

1. .env の比較・調整（結果：原因ではなかった）

2. .wslconfig で localhostForwarding=true（効果なし）

3. Vite に --host 0.0.0.0 を付ける（途中までは正解）

新たなエラー：0.0.0.0:5174 への ERR_ADDRESS_INVALID

4. .env に VITE_DEV_SERVER_URL を書いてみる（効かなかった）