.htaccess構文チェッカー

.htaccessファイルの内容を貼り付けるだけで、ブロックタグの閉じ忘れ・ディレクティブ名のスペルミス・RewriteRuleの引数不足・孤立したRewriteCondなど典型的な書き間違いをその場で検出します。

Tips

  • このチェッカーは行単位のヒューリスティックな静的解析であり、本物のApacheパーサーではありません。反映前には必ず実サーバーかステージング環境で動作確認してください。
  • Apache本体を管理できる環境であれば、apachectl configtestコマンドが最も確実な構文チェック手段です。本ツールはそれが使えない共有サーバー等での事前チェック用途を想定しています。
  • ディレクティブ名のtypo警告は許可リストとの照合による低確度の推測です。マイナーなモジュールのディレクティブを使っている場合は警告が出ても正しいことがあります。
  • RewriteCondは複数行連続して積み上げるのが通常の書き方です。最後のRewriteCondの直後にRewriteRuleが無い場合のみ警告として検出します。
  • 本番環境へのアップロード前に変更点だけを部分的に適用し、既存の動作に影響が無いか段階的に確認する運用がおすすめです。

よくある質問

最も多い原因は、Apache本体の設定(httpd.confやサイトの設定ファイル)でAllowOverride Noneになっており、そもそも.htaccessの内容が無視されている状態です。サーバー管理者にAllowOverride Allまたは必要な項目(AuthConfig・FileInfo等)が有効か確認してもらう必要があります。ブラウザ・CDN側のキャッシュが残っている可能性も合わせて確認してください。

基本形はRewriteRule パターン 置換先 [フラグ]の3要素です。パターンは正規表現でリクエストされたURLパス(先頭のスラッシュを除いた部分)にマッチさせ、置換先には$1等でパターン内の括弧グループを参照できます。フラグは[L](以降のルール処理を終了)や[R=301](恒久リダイレクト)のように角括弧内にカンマ区切りで指定します。

書き換え後のURLが再度同じRewriteRuleのパターンにもマッチしてしまい、Apacheが同じ書き換えを繰り返してしまうことが典型的な原因です。書き換え先のパスやファイルが実在する場合はそこで処理が止まるよう、RewriteCondで%{REQUEST_FILENAME} !-f(ファイルとして実在しない場合のみ)のような条件を先に付けるのが定石です。

多くの共有ホスティング環境では、該当ディレクトリ以下のすべてのページで「500 Internal Server Error」が表示されるようになります。エラーログ(利用可能であればerror_log)に具体的な行番号とエラー内容が出力されるため、まずはそちらを確認するのが最短の対処法です。

いいえ、保証はできません。このツールは行単位の正規表現によるヒューリスティックな静的チェックであり、実際のApacheパーサーの挙動を完全に再現しているわけではありません。有効なモジュール(mod_rewrite等)が読み込まれているか、ディレクティブがそのコンテキストで許可されているか等はサーバー環境依存のため、必ずステージング環境や実サーバーでの動作確認を行ってください。
ツールくん

余談ですが ― なぜ.htaccessという名前になったのか

.htaccessという名前は「hypertext access(ハイパーテキストへのアクセス)」の略で、1995年頃のNCSA httpdおよびApacheの初期バージョンにまで遡る歴史を持ちます。当初はディレクトリ単位でパスワード認証(Basic認証)を設定する目的で導入され、サーバー管理者がメインの設定ファイル(httpd.conf)を触らずに、各ディレクトリの持ち主が自分の管轄範囲だけ設定を上書きできる仕組みとして設計されました。

.htaccessが強力なのは、AllowOverrideディレクティブでApache側が許可さえしていれば、FTPやファイルマネージャーでアップロードするだけで即座に設定が反映される点です。共有ホスティング環境のようにサーバー本体の設定ファイルを編集する権限が与えられないユーザーでも、リダイレクト・キャッシュ制御・アクセス制限などをディレクトリ単位で細かく制御できます。

一方でこの手軽さには代償もあります。Apache公式ドキュメントは「サーバー設定ファイルへのアクセス権があるなら.htaccessではなくそちらに書くべき」と明言しています。理由は単純で、.htaccessはApacheがリクエストのたびに該当ディレクトリからルートまで遡って毎回読み込み直すため、メインの設定ファイルに書く場合と比べてパフォーマンスに無視できないオーバーヘッドが生じるためです。

また構文エラーが混入すると、多くの共有ホスティング環境では該当ディレクトリ全体が真っ白な「500 Internal Server Error」になり、原因の特定に時間を取られがちです。エディタでの目視確認だけでなく、こうした静的チェッカーを間に挟むことで、ケアレスミスによる公開後の事故を未然に防ぎやすくなります。