KapsuleHost における .htaccess の理解

KapsuleHost 上の .htaccess について理解する

Kapsule は、.htaccess を読み込まない高性能 Web サーバーですべての Web サイトを提供しているため、そのファイルに追加したルールは効果がありません。このガイドは、WordPress サイトにとってそれが何を意味するのかを説明し、その代わりに各タスクを実行する KPanel 設定を示します。

shared cPanel ホストから移行した場合、.htaccess はおそらく、リダイレクト、HTTPS の強制、カスタム エラー ページ、およびボット ブロックを配置する場所でした。これらのすべてが Kapsule で引き続き機能します。ただし、テキスト ファイルではなく KPanel で設定され、サーバー レベルで適用されるため、より高速であり、タイプミスでサイトを破壊することはできません。

.htaccess がここで機能しない理由

.htaccess は Apache Web サーバーのディレクトリごとの構成ファイルです。Apache は要求のたびに再度読み込みます。これはそれを便利にするものですが、同時に遅くするものです。

Kapsule は Apache を実行していません。サイトはイベント駆動型 Web サーバーで提供され、起動時に構成を 1 回読み込みます。これが、ここのサイトが負荷の下でより高速に応答する理由の大きな部分です。そのサーバーにはディレクトリごとのオーバーライド ファイルに相当するものがないため、.htaccess を開くことはありません。

良いニュースは、通常の .htaccess ホラー ストーリーの逆です: ファイルの構文エラーはここでサイトを破壊することはできません。何も解析していないためです。

それなしでも機能するもの

パーマリンク。 WordPress サイトが Apache で .htaccess を必要とする最も一般的な理由は、見栄えの良いパーマリンクです。Kapsule では、書き換えはサイトのサーバー構成に組み込まれているため、/2026/07/my-post/ は .htaccess ブロックなしで WordPress を通じて解決されます。パーマリンクが 404 を返している場合、原因は別のものです。WordPress パーマリンク問題の修正 を参照してください。

ファイルに書き込む WordPress。 WordPress と一部のプラグインは、Apache を想定しているため、# BEGIN/# END ブロックを .htaccess に書き込み続けます。これは無害です。ファイルは実在し、書き込み可能で、ファイル マネージャーに表示されます。単に読み込まれないだけです。

「セキュリティ強化が適用されました」と報告するセキュリティプラグイン。 xmlrpc.php または wp-config.php をロックダウンしたと主張するプラグインは、.htaccess を編集することで、このプラットフォームで実際には何も保護していません。サイト自身の Security タブを使用してください。サーバーで同等のルールが適用されます。

一般的な .htaccess ルールの KPanel での同等物

これらのすべてはサイト自体にあります: Websites、サイト、表示されているタブの順です。

これらのうち 2 つは、.htaccess バージョンがこれまでにできたことよりも多くのことを行います。リダイレクトは正確なパス、末尾のスラッシュプレフィックス、/blog/* などのワイルドカードをサポートし、KPanel は保存後にリダイレクトをライブで検証します。エラー ページはその真のステータス コードで提供されるため、カスタム 404 ページは、200 と謝罪ではなく、検索エンジンにとって本当の 404 です。

ファイルの検索と読み込み

プラグインが書き込んだものを確認したり、KPanel で再作成する前にルールをコピーアウトしたりするために、.htaccess を見たい場合があります。

WordPress タブから

1. KPanel にサインインし、左サイドバーの Websites をクリックします。
2. 目的のサイトをクリックします。
3. WordPress タブを開き、wp-config セクションを開きます。
4. .htaccess パネルまでスクロールします。コンテンツは読み取り専用で表示され、変更する必要がある場合は Edit ボタンがあります。

ファイル マネージャーから

1. サイトを開き、Files を開き、File Manager を開きます。
2. ツールバーの Show Hidden をクリックします。ドットで始まるファイルはデフォルトで非表示になっているため、これを実行するまで .htaccess は表示されません。
3. .htaccess をクリックして、組み込みエディターで開きます。

ファイルはサイトのルートに位置し、wp-config.php および wp-content の横にあります。エディターとそのアクセス許可コントロールの詳細については、ファイル マネージャーの使用 を参照してください。

デフォルトの WordPress ブロック

参考までに、これは WordPress が自身のために書き込むブロックです。Apache ホストでは、パーマリンクを駆動します。Kapsule ではそれは不活性で、削除しても何も破壊されません:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

後でサイトを Apache ホストに移動する可能性がある場合は、そのまま残します。パーマリンク設定を保存するたびに、WordPress は再度それを書き直します。

ルールを移行する場合

cPanel からサイトを持ってくる場合は、古いホスティングをキャンセルする前に古い .htaccess を開き、行ごとに作業してください:

1. リダイレクト。 Advanced で各 Redirect または RewriteRule を再作成し、Redirects を実行します。ルールごとに 1 行。永続的な移動の場合は 301 を選択し、変更が逆転する可能性がある場合は 302 を選択します。
2. HTTPS の強制。 削除します。代わりにサイトの Settings で Force HTTPS をオンにします。
3. IP ブロック。 WordPress、Security で IP ブロック パネルで再作成します。
4. キャッシングと圧縮ヘッダー。 削除します。それらはあなたのために処理されており、古いホストからの古い mod_expires ルールは、混乱したキャッシュ動作の一般的な原因です。
5. プラグインが書き込んだもの。 無視します。新しいサイトにプラグインを再インストールしてその機能を実行させてください。

移行はファイル自体を保持するため、リスト全体を処理している間、何も失われません。完全な移行ウォークスルー: cPanel からの Web サイト移行。

トラブルシューティング

「リダイレクトを .htaccess に追加しましたが、何も起こりませんでした。」 予期した通り。Advanced、Redirects で追加します。そこの Status 列は、リダイレクトがライブで検証されたかどうかを示します。

「プラグインはサイトが強化されていると言っていますが、スキャナーは同意していません。」 プラグインは読み込まれていない .htaccess ルールを書き込みました。サイトの Security タブで、実際に適用されている保護を確認してください。

「古いホストの .htaccess に理解していないルールがありました。」 ブラインドでコピーしないでください。ファイルをアタッチしてチケットを開いてください。Kapsule に相当するものがあるかどうか、または shared Apache ホストを補うためだけだったかを教えます。

「パーマリンクが壊れています。」 これはここの .htaccess 問題ではありません。WordPress パーマリンク問題の修正 にアクセスするか、サイトの WordPress タブから書き換えルールをフラッシュしてから、Quick Actions、Flush Rewrites の順に選択します。