PowerShellでスクリプト実行できない時の切り分け方―wrangler pages devが応答しない原因

この記事で切り分けられること

wrangler pages dev が「Ready」と表示されるのに、同じPC上から叩いたcurlが応答しない場合の切り分け方。あわせて、Git Bashから taskkill でプロセスを止めようとしても効かない、という現象の原因と、PowerShellでの代わりの止め方を書く。

症状

2026-10-25、ローカルで wrangler pages dev を起動すると「Ready」と出るが、curl で8788番に投げても60秒待って応答が返らない。netstat で確認すると、同じ8788番で LISTENING になっているプロセスが3〜4本見つかった。

netstat -ano | findstr 8788

1本のはずのポートに複数のプロセスがぶら下がっている状態だった。

原因

原因は、配備の検査(deploy_public_site・test_external_browser)を何度も走らせた際に起動した wrangler および workerd のプロセスが、検査終了後も残り続けていたこと。手元で確認した時点で43プロセスが溜まっていた。同じ8788番を複数のプロセスが取り合う形になり、どれが応答するか定まらず、要求が宙に浮いて応答が返らない状態になっていた。

さらに、これを止めようとしてGit Bashから次のコマンドを打っても効かなかった。

taskkill /PID 12345 /F

Git Bash(MSYS)環境では、スラッシュで始まる引数がパスとして解釈されてしまい、/PID がパスに化けて taskkill に正しく渡らない。これが「powershell スクリプト実行できない」「コマンドが効かない」ように見える原因の一つだった。taskkill 自体はPowerShellやコマンドプロンプトから実行する前提のコマンドで、Git Bashのパス変換と相性が悪い。

直し方

Git Bashではなく、PowerShellを開いて作業する。まず、残っている wrangler 関連プロセスをコマンドラインから特定して止める。

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'wrangler' } | Stop-Process -Force

wrangler の配下で動く workerd も同様に全部止める。

Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'workerd' } | Stop-Process -Force

全部止めたあとに、8788番を使うプロセスがいないことを確認する。

Get-NetTCPConnection -LocalPort 8788 -State Listen

何も出てこなければポートが空いている状態。ここで初めて wrangler pages dev を1本だけ起動し直す。

cd C:/Users/<あなたのユーザー名>/<プロジェクトのパス>
wrangler pages dev

起動後、もう一度 Get-NetTCPConnection で8788番のLISTENINGが1本だけになっていることを確認してから curl を叩く。

それでも駄目なときに次に見る場所

• Get-NetTCPConnection で8788番を見て、LISTENINGが複数残っていないか再確認する。1本に絞れていなければ、Stop-Process の対象漏れがある。
• deploy_public_site や test_external_browser など、wrangler pages dev を起動する検査スクリプト側で、終了時に wrangler を確実に止める処理が入っているか確認する。検査が異常終了した場合にプロセスが残る作りになっていないか見る。
• PowerShellのコマンドがそもそも実行できない(実行ポリシーで止まる、.ps1が開けないなど)場合は、Git Bashやコマンドプロンプトから .ps1 を直接呼んでいないか確認する。PowerShell用のコマンドはPowerShellの窓から実行する。
• 手元の検証を始める前に、毎回 Get-NetTCPConnection -LocalPort 8788 -State Listen を実行する習慣にすると、プロセスの溜まりに早く気づける。