.htaccess構文チェッカー
.htaccessファイルの内容を貼り付けるだけで、ブロックタグの閉じ忘れ・ディレクティブ名のスペルミス・RewriteRuleの引数不足・孤立したRewriteCondなど典型的な書き間違いをその場で検出します。
.htaccessの書き間違いを見つける
`.htaccess` は1文字の誤りでサイト全体が 500 エラーになりうるファイルです。このツールは内容を貼り付けるだけで、ブロックタグの閉じ忘れ・ディレクティブ名の綴り誤り・`RewriteRule` の引数不足・孤立した `RewriteCond` といった典型的な書き間違いをその場で検出します。
**ここで確かめられるのは構文であって、意図どおり動くかどうかではありません。** 書式として正しいリライト規則でも、条件の順序が違えば望んだURLには飛びません。そのうえで知っておきたい仕様が2つあります。ひとつは **`RewriteCond` が直後の `RewriteRule` 1つにしか掛からない**ことで、条件だけを並べて最後にまとめて規則を置く、という書き方は成立しません。もうひとつは、**サーバー側の設定で `AllowOverride` が無効になっていると、`.htaccess` はそもそも読まれない**という点です。「書いたのに何も起こらない」ときは、ファイルの中身ではなくサーバー設定を疑ってください。
使い方
- .htaccess の内容を貼り付ける ファイル全体をそのまま入れてください。
- サンプルで挙動を確かめる 正常な例とエラーを含む例が用意してあります。
- 指摘された行を読む **閉じ忘れや引数不足が、行番号つきで示されます。**
- 動かないときはサーバー設定も見る **`AllowOverride` が無効なら、ファイルは読まれません。**
使いこなすためのヒント
- このチェッカーは行単位のヒューリスティックな静的解析であり、本物のApacheパーサーではありません。反映前には必ず実サーバーかステージング環境で動作確認してください。
- Apache本体を管理できる環境であれば、
apachectl configtestコマンドが最も確実な構文チェック手段です。本ツールはそれが使えない共有サーバー等での事前チェック用途を想定しています。 - ディレクティブ名のtypo警告は許可リストとの照合による低確度の推測です。マイナーなモジュールのディレクティブを使っている場合は警告が出ても正しいことがあります。
- RewriteCondは複数行連続して積み上げるのが通常の書き方です。最後のRewriteCondの直後にRewriteRuleが無い場合のみ警告として検出します。
- 本番環境へのアップロード前に変更点だけを部分的に適用し、既存の動作に影響が無いか段階的に確認する運用がおすすめです。
活用シーン
本番へ反映する前に確かめる
**`.htaccess` の誤りはサイト全体を落とすため、事前の確認が効きます。**
リライト規則を書き足す
既存の規則に条件を追加したあと、書式が崩れていないかを見られます。
引き継いだ設定を読み解く
長く継ぎ足されたファイルの中に、効いていない記述が無いかを確かめられます。
500エラーの原因を絞る
**サーバーが起動しない原因が構文にあるのかどうかを、最初に切り分けられます。**
.htaccessの用語
- RewriteEngine
- リライト機能を有効にする指定です。**これを `On` にしないと、以降の規則は一切効きません。**
- RewriteCond
- リライトの条件です。**直後の `RewriteRule` 1つにしか掛からない**点に注意が必要です。
- RewriteRule
- 書き換えの規則本体です。パターンと置換先、そして `[L,QSA]` のようなフラグを取ります。
- フラグ
- 規則の後ろの角かっこ内の指定です。`L` はここで処理を止める、`QSA` はクエリ文字列を引き継ぐ意味です。
- ブロックタグ
- `
` や ` ` のような囲みです。**閉じ忘れると 500 エラーになります。** - AllowOverride
- `.htaccess` にどの指定を許すかを決めるサーバー側の設定です。**無効なら `.htaccess` は読まれません。**
よくある質問
AllowOverride Noneになっており、そもそも.htaccessの内容が無視されている状態です。サーバー管理者にAllowOverride Allまたは必要な項目（AuthConfig・FileInfo等）が有効か確認してもらう必要があります。ブラウザ・CDN側のキャッシュが残っている可能性も合わせて確認してください。RewriteRule パターン 置換先 [フラグ]の3要素です。パターンは正規表現でリクエストされたURLパス（先頭のスラッシュを除いた部分）にマッチさせ、置換先には$1等でパターン内の括弧グループを参照できます。フラグは[L]（以降のルール処理を終了）や[R=301]（恒久リダイレクト）のように角括弧内にカンマ区切りで指定します。%{REQUEST_FILENAME} !-f（ファイルとして実在しない場合のみ）のような条件を先に付けるのが定石です。error_log）に具体的な行番号とエラー内容が出力されるため、まずはそちらを確認するのが最短の対処法です。
余談ですが ― なぜ.htaccessという名前になったのか
.htaccessという名前は「hypertext access（ハイパーテキストへのアクセス）」の略で、1995年頃のNCSA httpdおよびApacheの初期バージョンにまで遡る歴史を持ちます。当初はディレクトリ単位でパスワード認証（Basic認証）を設定する目的で導入され、サーバー管理者がメインの設定ファイル（httpd.conf）を触らずに、各ディレクトリの持ち主が自分の管轄範囲だけ設定を上書きできる仕組みとして設計されました。
.htaccessが強力なのは、AllowOverrideディレクティブでApache側が許可さえしていれば、FTPやファイルマネージャーでアップロードするだけで即座に設定が反映される点です。共有ホスティング環境のようにサーバー本体の設定ファイルを編集する権限が与えられないユーザーでも、リダイレクト・キャッシュ制御・アクセス制限などをディレクトリ単位で細かく制御できます。
一方でこの手軽さには代償もあります。Apache公式ドキュメントは「サーバー設定ファイルへのアクセス権があるなら.htaccessではなくそちらに書くべき」と明言しています。理由は単純で、.htaccessはApacheがリクエストのたびに該当ディレクトリからルートまで遡って毎回読み込み直すため、メインの設定ファイルに書く場合と比べてパフォーマンスに無視できないオーバーヘッドが生じるためです。
また構文エラーが混入すると、多くの共有ホスティング環境では該当ディレクトリ全体が真っ白な「500 Internal Server Error」になり、原因の特定に時間を取られがちです。エディタでの目視確認だけでなく、こうした静的チェッカーを間に挟むことで、ケアレスミスによる公開後の事故を未然に防ぎやすくなります。