IIS + PHPで404になったときの確認ポイント

IISにPHPアプリを配置してアクセスしたら、

このページが見つかりません HTTP ERROR 404

と表示された。

このとき、いきなりRewriteやPHPの設定を片っ端から触るより、

「どこまで正常に動いているか」

を順番に確認した方が切り分けやすい。

今回、Windows Server + IIS + PHP + CodeIgniterの環境を構築したときに実際に404でハマったので、そのときの確認方法を整理しておく。

実際にハマった流れはこちら。

IISでPHPを動かしたら404になった話

まず確認する順番#

今回の構成では、大きく分けるとこうなっていた。

1
ブラウザ
2
↓
3
IIS
4
↓
5
FastCGI
6
↓
7
PHP
8
↓
9
index.php
10
↓
11
CodeIgniter
12
↓
13
DB

404が出たときに重要なのは、

この中のどこで止まっているのかを確認すること。

自分の場合、最初はIIS周辺をかなり調べたけど、最終的には index.php まで正常に到達していた。

なので今なら、次の順番で確認する。

1
1. 静的ファイルが表示できるか
2
2. PHP単体が動くか
3
3. index.phpまで到達しているか
4
4. アプリ側を確認する
5
5. DB接続など外部依存を確認する

順番に見ていく。

1. 静的ファイルが表示できるか#

まずPHPは置いておいて、IISが普通のファイルを配信できるか確認する。

たとえばIISの公開ディレクトリが、

1
C:\inetpub\wwwroot

なら、そこにテストファイルを作る。

PowerShellなら、

1
Set-Content -Path "C:\inetpub\wwwroot\iis-test.txt" -Value "IIS TEST"

ブラウザから、

1
http://localhost/iis-test.txt

へアクセスする。

IIS TEST と表示されれば、少なくともIISからそのファイルまでは到達できている。

ここで表示できないなら、まだPHPを疑う段階ではない。

IISのサイト設定、物理パス、ファイルの存在など、IIS側から確認する。

2. 本当にそのファイルは存在するか#

かなり基本的な話だけど、先にやっておいた方がいい。

PowerShellで、

1
Test-Path C:\inetpub\wwwroot\index.php

を実行する。

存在すれば、

1
True

が返る。

今回の調査では、PHPの確認用ファイルを、

1
info.php

という名前で作っていたのに、

1
http://localhost/phpinfo.php

へアクセスしていた。

当然404になる。

IISの詳細エラーには、

と出ていた。

いろいろ設定を疑う前に、

「そのURLのファイル、本当にその名前で存在する？」

は確認しておいた方がいい。

地味だけど、ここで結構な時間を溶かした。

3. PHP単体が動くか#

静的ファイルが表示できたら、次はPHP。

たとえば、

1
C:\inetpub\wwwroot\info.php

を作って、

1
<?php phpinfo();

とする。

ブラウザから、

1
http://localhost/info.php

へアクセス。

PHP情報が表示されれば、

1
IIS
2
↓
3
FastCGI
4
↓
5
PHP

までは動いていると判断できる。

ここでPHPが動かない場合は、アプリ側へ進む前にIISのPHP設定を確認する。

今回の環境では、IISのハンドラーマッピングを次のように設定していた。

1
要求パス: *.php
2
モジュール: FastCgiModule
3
実行可能ファイル: C:\PHP\7.3.33\php-cgi.exe

PHP自体が起動するかは、コマンドでも確認できる。

1
php.exe -v

今回、この時点でも一度ハマった。

PHP 7.3.33のWindows版を配置した直後は php.exe -v が正常に動かず、Visual C++ Redistributableをインストールすると起動するようになった。

なのでPHP単体が動いていないなら、FastCGIだけでなくPHPそのものが実行できるかも確認する。

4. index.phpまで届いているか#

PHP単体は動く。

index.php も存在する。

それでもアプリへアクセスすると、

ページが見つかりません

となる。

ここでIISの設定を延々と調べる前に、

本当に index.php まで届いていないのか

を確認する。

一時的に index.php の先頭へ、

1
<?php
2
echo 'INDEX OK';
3
exit;

を入れる。

ブラウザからアクセスして、

1
INDEX OK

と表示されたら、

1
IIS
2
↓
3
FastCGI
4
↓
5
PHP
6
↓
7
index.php

までは正常。

つまり、少なくとも、

「IISがindex.phpを見つけられない」

という問題ではない。

この確認は今回かなり効いた。

404を見てIIS周辺を調べていたけど、実際には index.php まで普通に処理が来ていた。

確認が終わったら、追加した echo と exit は戻しておく。

5. ここまで通ったらアプリ側を見る#

index.php まで正常に届いているなら、次はCodeIgniterなどアプリ側の確認へ進む。

今回なら、

1
IIS
2
↓
3
FastCGI
4
↓
5
PHP
6
↓
7
index.php  ← ここまで確認済み
8
↓
9
CodeIgniter

という状態。

この時点でIISの物理パスやPHPハンドラーを何度確認しても、原因には近づきにくい。

アプリのルーティングや設定、ログなど、index.php より後ろを見る。

CodeIgniter 3なら、ログの出力先として、

1
application/logs/

も確認対象になる。

ログが出ない場合は、application/config/config.php の、

1
$config['log_threshold']

や、IISのApplication Poolからログディレクトリへ書き込める権限があるかも確認する。

6. DB接続なども確認する#

アプリ自体が動き始めたら、DBなどアプリが依存している先も確認する。

今回の環境では、最終的にDB接続まわりがうまくいっていなかった。

そこを修正すると、アプリの画面まで表示されるようになった。

ただし今回については、

DB接続エラーそのものが404を返していたのか、DB接続に失敗した結果としてアプリ側の別処理が404を返していたのかまでは確認できていない。

なので、

IISで404が出たらDBを直せばいい

という話ではない。

重要なのは、index.php まで届いていると分かった時点で、

1
IISの問題

だけを追うのをやめて、

1
アプリ
2
DB
3
その他の依存先

まで調査範囲を移すこと。

web.configで500.19が出る場合#

今回、404になる前には、

1
500.19

も発生した。

原因は web.config にRewriteの設定があるのに、IISへURL Rewrite Moduleを入れていなかったことだった。

web.config に、

1
<rewrite>
2
    ...
3
</rewrite>

がある場合、IIS側でURL Rewrite Moduleが利用できる状態か確認する。

今回の場合はURL Rewrite Moduleをインストールすると500.19は解消した。

ただし、その後に404が出た。

つまり、

1
500.19が消えた
2
=
3
アプリまで正常に動いた

ではない。

一個先へ進んだだけだった。

web.configを外して403.14になる場合#

切り分けの途中で web.config を無効化すると、

1
403.14

になったこともあった。

このときは、ディレクトリまでは見えているものの、既定のドキュメントが決まっていない状態だった。

今回試した設定は、

1
<defaultDocument>
2
    <files>
3
        <clear />
4
        <add value="index.php" />
5
    </files>
6
</defaultDocument>

これで / へのアクセス時に index.php を既定のドキュメントとして扱わせる。

Rewriteを調査するときは、

1
IISそのものの問題なのか
2
web.configの問題なのか
3
Rewrite後のアプリ側の問題なのか

を分けて考えると整理しやすい。

404が出たときの確認順まとめ#

今回の経験から、同じ構成ならこの順番で見る。

1
① 静的ファイル
2
   /iis-test.txt
3
        ↓
4
② PHP単体
5
   /info.php
6
        ↓
7
③ index.php
8
   echo + exit で到達確認
9
        ↓
10
④ アプリ
11
   ルーティング・設定・ログ
12
        ↓
13
⑤ DBなどの依存先

ポイントは、

404の原因をいきなり当てにいかないこと。

「IISかな？」

「Rewriteかな？」

「権限かな？」

と予想して設定を触り始めるより、

どこまで正常に通っているかを一段ずつ確定させる。

info.php が表示されるならPHPより前はかなり絞れる。

index.php の echo が表示されるなら、さらに先へ進める。

そうやって正常な範囲を確定していけば、調べる場所も自然に狭くなる。

実際にこれを逆方向から疑いまくって遠回りした話は、こっちに書いた。

IISでPHPを動かしたら404になった話

手順だけ知りたい人はこの記事で十分。

遠回りまで追体験したい人は本編へどうぞ。