⚙️ .htaccess ジェネレーター
チェックボックスで Apache .htaccess の機能を ON/OFF するだけで、HTTPS リダイレクト・HSTS・gzip 圧縮・キャッシュ・機密ファイル拒否・WordPress パーマリンクなどを含む本番運用レベルの .htaccess をリアルタイム生成。
🔒 プライバシーについて
- ・すべての生成処理はあなたのブラウザ内で完結します
- ・入力したドメイン名・設定値はサーバーに送信されません
- ・保存ログ・ユーザー追跡・データベース等は存在しません
🧩 機能の選択
📄 生成された .htaccess
📖 つまずきやすいポイント
HTTPS へのリダイレクト、www の統一、PHP バージョン指定 (Xserver / さくら)、キャッシュ制御、セキュリティヘッダー、アクセス制限などを組み合わせて .htaccess を生成します。処理はブラウザ内で完結します。.htaccess には、他の設定ファイルには無い危険な性質があります — 1 行の誤りで、そのディレクトリ以下のすべてが即座に 500 エラーになります。しかもエラー画面は原因を教えません。管理画面も同じ範囲に入っていれば、そこからは直せません — 編集する前に、戻す手段があるかを確認してください。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 1 行の誤りでサイト全体が 500 になる | .htaccess はリクエストのたびに読み直されるので、誤りは保存した瞬間から全リクエストに影響します。最も多い原因は読み込まれていないモジュール向けのディレクティブです — mod_headers が無効な環境で Header set ... と書けば、Apache はその行を理解できず 500 Internal Server Error を返します。「文法は正しいのに動かない」ではなく「設定が読めないので全部止まる」のが厄介な点です。そして表示されるのは汎用のエラーページだけで、何行目の何が問題かは書かれていません — その情報はサーバーのエラーログにしかありません。共有ホスティングでログを見られない環境では、原因の特定が総当たりになります。 |
モジュール依存のディレクティブは必ず <IfModule> で囲んでください。 <IfModule mod_headers.c> の中に書けば、モジュールが無い環境では単に無視されるだけで、500 にはなりません — これだけで事故の大半が防げます。作業手順としては、編集前に必ずコピーを取り、SSH や FTP のように「サイトが 500 でも使える経路」から編集してください — WordPress の管理画面から編集するのは、自分の足場を壊す作業です。そして小さく足して、その都度ブラウザで確認してください — 10 行まとめて追加してから 500 になると、どれが原因かを二分探索することになります。共有ホスティングなら、まずエラーログを見られるかどうかを先に確かめておくと、いざというときに困りません。 |
| リダイレクトがループする / 301 が消せない | HTTPS への強制と www の統一を同時に書くと、条件の順番次第で無限ループになります。とくにロードバランサや CDN が前段にいる構成では、サーバーには常に HTTP で届くため %{HTTPS} がいつまでも off のままで、リダイレクトが永久に繰り返されます — 症状は ERR_TOO_MANY_REDIRECTS です。そしてここに 301 の性質が重なります: 301 は「恒久的」なのでブラウザが強くキャッシュし、設定を直したあともブラウザは古いリダイレクトを実行し続けます。結果として「直したのに直らない」という状態になり、さらに設定をいじって事態を悪化させる — これがこの手のトラブルで最も時間を失うパターンです。 |
プロキシの後ろにいるなら %{HTTP:X-Forwarded-Proto} を見てください。 RewriteCond %{HTTP:X-Forwarded-Proto} !https と書けば、CDN 経由でも正しく判定できます。そして検証は必ずブラウザではなく curl -I で行ってください — curl はリダイレクトをキャッシュしないので、常に現在の設定の結果が見られます。作りかけの段階では 302 を使い、意図どおりに動くことを確認してから 301 に変える — この順序だけで、キャッシュに起因する事故はほぼ全部避けられます。すでに間違った 301 を配ってしまった場合は、正しい先へ改めて 301 を返すのが唯一の対処です — ブラウザのキャッシュは、あなたからは消せません。そしてリダイレクトのルールは 1 か所にまとめてください — 複数の .htaccess やアプリ側の設定に分散していると、ループの原因が追えなくなります。 |
サブディレクトリの .htaccess が親のルールを打ち消す |
.htaccess は階層的に適用されますが、mod_rewrite のルールだけは「継承」ではなく「置き換え」です。サブディレクトリに RewriteRule を 1 つでも書いた瞬間、親ディレクトリの書き換えルールはそのディレクトリでは無効になります — HTTPS への強制も、www の統一も、そこだけ効かなくなります。気付きにくいのは、他のディレクティブ (認証・キャッシュ・ヘッダー) は普通に継承されるからです — 「一部だけ継承される」という直感に反する挙動になります。関連して、サブディレクトリでは RewriteBase の指定が必要になる場合があり、これを書き忘れると相対パスが親のパスとして解決され、404 やループを引き起こします。 |
可能なら .htaccess を使わず、サーバー本体の設定に書いてください。 VPS や専用サーバーなら <Directory> ブロックに書けます — リクエストのたびにファイルを探して読む処理が無くなるので、速度でも有利です (AllowOverride None にすると Apache は探しにさえ行きません)。共有ホスティングで .htaccess しか使えない場合は、書き換えルールを親 1 か所に集約し、サブディレクトリには RewriteRule を置かないようにしてください。どうしても必要なら RewriteOptions Inherit を書けば親のルールを引き継げますが、適用順序が変わるので、その場合は必ず全パターンを実際に叩いて確認してください。 |
セキュリティヘッダーは、付ければ安全になるものではありません。X-Frame-Options や Content-Security-Policy は特定の攻撃手法を封じるだけで、アプリケーション側の脆弱性には何の効果もありません — 診断ツールの点数が上がることと、実際に安全になることは別です。とくに Content-Security-Policy は、付け方を間違えると自分のサイトの JavaScript が動かなくなります — まず Content-Security-Policy-Report-Only で様子を見てから本番の指定に切り替えてください。もうひとつ、.htaccess でのアクセス制限は「そのファイルが Apache 経由で配信されるとき」にしか効きません — nginx が前段で静的ファイルを直接返す構成では、.htaccess はそもそも読まれません。機密ファイルは公開ディレクトリの外に置くのが本筋で、アクセス制限で隠すのは次善の策です。そして忘れがちですが、.htaccess 自体もバージョン管理してください — いつ誰が何を足したのかが分からない設定ファイルは、いずれ誰も触れなくなります。
📖 使い方
-
1
機能を選ぶ左のチェックボックスから有効にしたい機能 (HTTPS リダイレクト・HSTS・gzip など) を選択。右側にリアルタイムでプレビューが出ます。
-
2
ドメイン名を入れるwww 正規化を使う場合はドメイン名 (例: example.com) を入力。HTTPS リダイレクトのみであれば不要です。
-
3
コピー or ダウンロード右上のボタンでクリップボードにコピー、またはファイルとしてダウンロード。中身を確認してからサーバーへ。
-
4
サーバーに配置ドキュメントルート直下 (public_html / htdocs / public 等) に .htaccess として配置。既存ファイルがある場合はバックアップしてから差し替え。
❓ よくある質問
.htaccess は Apache 以外でも使えますか？
500 エラーが出たらどうすれば？
共有サーバー (Xserver / さくら) でも使えますか？
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。