.htaccessの500エラーを解決！9個の原因をチェックしよう
.htaccessの設定時にエラーが出て動かない場合、それを解決できる可能性のある9つのポイントをまとめてみました。
ファイル名や記述ミス、Basic認証時のhtpasswdファイルの絶対パス、改行コード、パーミッションなど様々な原因が考えられます。
落ち着いて一つずつチェックをしていくよう心掛けて下さい。
１：ファイル名称の確認
.htaccessを設置はしてみたものの、上手く動かない事ってよくありますよね。
本記事では想定できる限りのエラーケースを紹介するつもりですが、その前にまずは基本的なおさらいをさせて頂きます。
ファイル名に注意しよう
.htaccessのファイル名はそのまま.htaccessになります。先頭に「.」ドットがある事に注意して下さいね。
ファイル名の前後に半角や全角のスペースが入っていたりしてもダメです。
拡張子はつけない
特にWindowsの初期の状態では「拡張子の表示」がOFFになっています。
ですのでファイル名が「.htaccess.txt」となっている場合があります。
「.htaccess.txt」と拡張子が付いている状態では正しく動作しないため、拡張子部分を削除しましょう。
そして名前を「.htacess」のみにして下さい。
サーバーにUPした後に名前変更する手も
たまに拡張子が自動で付与されて「.htaccess」というファイル名にできない場合があります。
その場合は一旦「.htaccess.txt」のままでサーバーにアップロードをして、サーバーに置いた後に「.htaccess」にリネームしましょう。
サーバーにアップした後に名前変更
２：.htaccessの記述ミスを探そう
ファイル名に間違いが無いのであれば次の工程です。
構文スペルの間違い
.htaccessの記述にミスがないかどうか、もう一度確認してみる必要がありますね。
正規表現やmod_rewrite構文の単純なスペルミス、エスケープ漏れが起きていないかなどチェックをしましょう。
「^」や「$」「.*」などが複雑に絡んでいますが、その全てに意味がありますので一つずつ確認する必要がありますね。
エラーがあれば「500サーバーエラー」
基本的に.htaccessは、書き方を間違えると「500 internal server error」と言うエラーページが表示されるようになっています。
具体的には以下のような画面が表示されWEBページが表示されなくなります。
.htaccessを書く時は記述ミスに注意しましょう。
３：Basic認証時のエラー
Basic認証は設置する頻度も高い分、よくエラーが出たりしますよね。
.htaccessや.htpasswdのファイル名が違っていたり、.htpasswdの設置場所のパスを間違えている場合があるようです。
設置場所とサーバーパス（指定パス）を確認して見ましょう。サーバーパスはレンタルサーバーごとに違うので注意して下さいね。
サーバーパス（フルパス・絶対パスなど呼び方あり）について
例えばロリポップサーバーの場合、サーバーパスは管理画面の「アカウント情報」ページに載っています。
/home/users/2/main.jp-lpeg.info/web
のような感じのフルパスになります（上記は架空）。
これを参照しながら、.htpasswdを設置したURLを記載する必要があります。
.htaccessの絶対パス部分の表記
#サーバーパス表記ここから AuthUserFile /home/users/1/main.jp-lpeg.info/web/contents/test/.htpasswd #ここまで AuthGroupFile /dev/null AuthName "Input ID and Password." AuthType Basic require valid-user
それでも上手く動かない時
それでも動かない場合は上記の記述より、「AuthGroupFile /dev/null」部分を削除してみて下さい。
エラーが解消される場合があります。
４：最後に必ず1行改行が入っている事
.htaccessの一番最後の行には「改行が1行」入っている必要があります。
一番下の段に必ず一つ余白を作るようにしましょう。
最後は必ず1段以上の改行を入れる事
５：.htaccessの改行コード
よくネットで調べたコード情報を部分そのままコピペして利用する場合、何故か.htaccessがうまく動かない場合があります。
この様なときは、.htaccessファイルの改行コードに気を付けてみて下さい。
LF・CR・CRLF文字コードについて
.htaccessでは、LF（ラインフィード）を改行コードとして認識するようになっています。
LFは、UNIX・Linux、MacOSX以降で一般的に使用されている改行コードです。
まれにMacで編集したファイルがCR（キャリッジリターン）を改行コードとして含む場合があります。
CRは、MacOS9以前のMacで使用されている改行コードですね。
例えばWindowsで一般的に使用されている改行コードは両者を混合した「CRLF」になります。このCRLFであれば認識をしてくれます。
サクラエディタでの改行コードの確認
本来のLFか、或いはCRLFの改行コードになっているかどうかをテキストエディタで確認するようにしましょう。
サクラエディタの窓右下に改行コードや文字コードが表示されています。
保存する時の文字コード
.htaccessは基本、文字コードはutf-8のBOMなしで保存するようになっています。
６：パーミッションは「604」へ
サーバーにUPした後ファイルのパーミッションは「604」になっているかを確認しましょう。
604以外の場合正常に動作しない場合があります。
サーバー環境によっては「644」と指定されているところもありますので、サーバー環境を確認して下さいね。
７：ブラウザのキャッシュ機能に注意
Google Chromeを始めとする最近のWEBブラウザは、301リダイレクトの転送が成功するとリダイレクト先のURLをブラウザ上でキャッシュするようになっています。
ですのでそのあと再度.htaccessの設定を変更しても、キャッシュ機能により301リダイレクト先のURLに勝手に転送し続けてしまうのですね。
正式に決定するまでは302リダイレクトで
WEBサイトの表示速度を早めてくれる意味では重宝するのですが、開発中の段階では面倒な面もあります。
これを解決するためには、.htaccessの設定内容をテストしている時は、フラグを「R=302」と設定しておく事です。
そうすればChromeのキャッシュ機能を回避できます。
８：リダイレクト処理で403エラーが出る場合
.htaccessの書き方はあっているのにどうしても403エラーが出る場合は、下記のように「+FollowSymLinks」を追加してみて下さい。
Options +FollowSymLinks
上記をどこかに追加する事でエラーが解消されるはずですので、403エラーが出た人は上記の一文を追記してみましょう。
９：.htaccessの設置場所・影響範囲
基本的にはファイルを設置した位置（ディレクトリ）から下にある全てのファイルへ影響を及ぼします。
index.htmlやindex.phpなどがあるTOPディレクトリ内に設置をすれば、そのサイト全体に効果が及ぶ事になります。
.htaccessファイルは、下の階層にも複数設置することが可能です。
TOPディレクトリ以外に下の階層に別の.htaccessを設置した場合は、下の階層にあるルールの方が優先されます。
ですので下のディレクトリに設置してあるhtaccessが邪魔をして設定が反映されない事もあります。
