Apache 2.4 + PHP-FPM (FastCGI) on Windows 11で出る「Proxy Error / DNS lookup failure」を確実に直す方法

この記事では、Apache 2.4 が Windows 11 上で PHP-FPM（FastCGI）へプロキシするときに発生する「Proxy Error — DNS lookup failure for: 127.0.0.1:9082c:」の原因と、短期対処から安全で確実な設定までをわかりやすく整理します。Windows 固有のファイルパス（ドライブレター）の扱いによる設定パースの誤りが根本原因で、エラーメッセージが DNS 問題として現れる点を中心に、実務で役立つ手順とポイントをまとめます。

Apache 2.4 + PHP-FPM (FastCGI) on Windows 11で出る「Proxy Error / DNS lookup failure」を確実に直す方法
実務的なチェックリスト（トラブルシュート手順）
よくある誤解と注意点
まとめ（対応手順の優先順位）

問題の概要（症状）

Apache による FastCGI プロキシで PHP を動かそうとすると、ブラウザに以下のようなエラーが出ることがあります。

表示されるエラー: Proxy Error — The proxy server could not handle the request
付随メッセージ: Reason: DNS lookup failure for: 127.0.0.1:9082c:

サーバ側の error.log には類似の行が記録されます（要点のみ示します）：

AH00898: DNS lookup failure for: 127.0.0.1:9082c: returned by /index.php

ポイントは「ポート番号の直後に 'c:' がくっついている」点です。これは C:\ のドライブレター（Windows のパス）がバックエンドアドレスに誤って結合されてしまっていることを表します。

なぜこうなるのか（技術的な原因）

mod_proxy_fcgi は、バックエンド（例: 127.0.0.1:9082）へリクエストを転送する際に、リクエスト先のスクリプトパス（SCRIPT_FILENAME のような情報）を構築します。
Linux/Unix 系ではパス区切りが / で一貫しているため比較的安全に推測できますが、Windows では C:\... のようにドライブレターが入るため、バックエンド URI の解析が曖昧だとパース時にポートの後ろへ C: が連結されてしまいます。
結果、127.0.0.1:9082（有効） → 127.0.0.1:9082c:（無効なホスト名）になり、Apache はそれを名前解決（DNS）しようとして失敗し、「DNS lookup failure」と報告されます。実態は DNS の問題ではなく設定パースの失敗です。

最短で効く「まず試す」対処

最も簡単でよく効くのは、バックエンド指定の末尾にスラッシュ / を付けることです。これにより Apache がバックエンド URL を「ホスト:ポート/」として扱い、後続のファイルパスを正しく連結します。

例（問題が起きている設定の該当箇所）：

問題箇所: SetHandler "proxy:fcgi://127.0.0.1:9082"
推奨（短期対処）: SetHandler "proxy:fcgi://127.0.0.1:9082/"

スラッシュを付けるだけで改善するケースは多く、まずはこれを試してください。

より堅牢で推奨される設定（Windows 環境向け）

運用で安定させるためには、単に末尾スラッシュを付けるだけでなく、ドキュメントルートを明示的にバックエンドへ渡す方法を採るのが望ましいです。推奨されるパターンは ProxyPassMatch を使って、リクエストごとに正しいファイルパスを構築して FCGI バックエンドへ渡す方法です（Windows のドライブレター表現を含めて明示します）。

例（VirtualHost 内に置く推奨設定）：

ProxyPassMatch "^/(.*\.php(/.*)?)$" "fcgi://127.0.0.1:9082/C:/server/www/82/$1"

この形式の利点：

バックエンドに渡すファイルパスを明示的に指定できる → 不正な結合や推測による誤動作を防げる。
PHP-FPM 側で受け取る SCRIPT_FILENAME が確実に正しい値になるため、環境依存のバグを避けられる。
Windows の C: のようなドライブレターが間違った位置に挿入されることを未然に防げる。

FilesMatch + SetHandler を使う場合の改善例

FilesMatch + SetHandler を使う構成でも、末尾に / を付け、かつ必要に応じてドキュメントルートを指定することで安定します。

SetHandler "proxy:fcgi://127.0.0.1:9082/C:/server/www/82/"

ただし ProxyPassMatch の方が柔軟で、複数サイトやパスに対するマッピングを一括で扱いやすいため、複雑な環境では ProxyPassMatch を推奨します。

実務的なチェックリスト（トラブルシュート手順）

Apache の設定を読み直す（特に SetHandler / ProxyPassMatch の記述）。末尾に / があるか確認。
PHP-FPM（または FastCGI 実装）が TCP で 127.0.0.1:9082 をリッスンしているか確認（Windows でソケットファイルは使えないため TCP が一般的）。
error.log を確認し、127.0.0.1:9082c: のような「余計な文字列」が付いていないかチェック。付いている場合はパス連結の失敗。
ProxyPassMatch を試し、ドキュメントルートを明示してみる。
設定変更後は Apache を再起動して反映させる。
ネットワーク的な接続確認： telnet 127.0.0.1 9082 などでポートが開いているか確認（Windows の場合は telnet クライアントを有効にする必要あり）。
PHP 側（php-fpm）のログも確認し、受信リクエストの SCRIPT_FILENAME が正しいか見る。

よくある誤解と注意点

ログに「DNS lookup failure」と出ると DNS 側の問題だと誤認しやすいが、多くは設定文字列のパースエラーであり、DNS を触っても解決しません。
Windows のパス表記（C:\… / C:/…）は Apache の URL 構築に影響するため、Windows 固有の注意が必要です。
設定のシンタックスエラーやスペースの有無で動作が変わることがあるため、細部まで正確に記述してください。

まとめ（対応手順の優先順位）

まずは SetHandler "proxy:fcgi://127.0.0.1:9082/" のように末尾スラッシュを付けて試す。
効果がない場合は ProxyPassMatch を使い、fcgi://ホスト:ポート/C:/path/to/docroot/$1 のようにドキュメントルートを明示的に渡す。
Apache と PHP-FPM のログを両方確認し、SCRIPT_FILENAME や受信パスが正しく設定されていることを確認する。
最後に必要ならば Windows 固有の権限やファイアウォール設定も確認する（ポートブロックがないか）。

この問題は一見 DNS エラーに見えますが、実態は Apache の設定文字列パースと Windows のファイルパス表現がぶつかった意外に単純な不具合です。まずは末尾スラッシュの追加、それでもダメなら ProxyPassMatch による明示的なパス渡しで確実に解決できます。設定を見直し、ログを手がかりに順を追って対応してください。