XserverのWAF誤検知で501エラー！コード付き記事が投稿できない原因と完全対策ガイド【WordPress】

検証環境：WordPress 6.9.4 / Xserver / PHP 8.3.21（2026年3月時点）

「WordPressで技術記事を投稿しようとしたら、突然501 Not Implementedエラーが出て更新できない！」

「画面には『MOVE/COPYなどのメソッドに対応していません』と表示されるけど、そんな操作した覚えがない…」

技術ブログを運営していると、一度はぶつかるこのトラブル。特に、PHPやJavaScript、シェルコマンドなどのコードサンプルを含む記事を書いているときに頻発します。

この問題の原因の多くはXserverのWAF（Web Application Firewall）が記事本文中の文字列を攻撃と誤認してブロックしていることにあります。WordPress自体が壊れたわけではありません。

この記事では、501エラーの「今すぐ復旧したい」という緊急対応から、「二度と同じ目に遭いたくない」という再発防止策まで、すべてを網羅した完全ガイドをお届けします。

原因：WAFがPOST本文を攻撃と誤認している

WordPressの記事投稿はPOSTメソッドで行われますが、XserverのWAFが記事本文中のコード（ls、curl、SELECT等）を攻撃パターンとして検知し、リクエストをブロックした結果として501エラーが表示されます。あなたが変なHTTPメソッドを送ったわけではありません。

エラー発生の流れは以下の通りです。WordPressから記事更新のPOSTリクエストが送信され、XserverのWAFがリクエスト本文（記事内容）をスキャンします。本文中の特定文字列が「攻撃パターン」としてマッチし、WAFがリクエストをブロック。その結果、Xserver側の汎用エラーページ（501）が返されます。

実際、複数の事例報告でWAFの「コマンド対策」をOFFにすると501エラーが解消したことが確認されています。

501 Not Implementedの技術的背景

HTTP仕様（RFC 9110）では501はサーバーがリクエストメソッドを実装していない場合に返すステータスコードですが、Xserverでの501エラーはWAFブロックの副産物であり、本来の意味とは異なります。WordPress操作中にこのエラーが出たらWAFを疑ってください。

HTTPの標準仕様であるRFC 9110では、501ステータスコードは「サーバーがリクエストメソッドをサポートしておらず、処理できないことを示す」と定義されています。本来はWebDAVのMOVEやCOPYといった特殊メソッドを、非対応サーバーに送った場合に返されるエラーです。

重要なのは、WordPressの通常操作ではMOVE/COPYメソッドは使用されないということです。記事の投稿・更新・削除はすべてGETまたはPOSTで行われます。したがって、WordPress操作中に501エラーが出た場合は、「何らかの防御レイヤー（WAF）がリクエストをブロックし、その結果として501エラーページが表示されている」と解釈するのが正確です。

Xserverでは、WAFによるブロック時に専用エラーページではなく汎用501エラーページが表示されることがあります。エラーメッセージの「MOVE/COPY」は実際の原因を正確に反映していないため、この表示に惑わされないでください。

XserverのWAFの仕組みと誤検知の理由

XserverのWAFにはXSS対策・SQL対策・ファイル対策・メール対策・コマンド対策・PHP対策の6項目があり、技術ブログで最も誤検知が多いのは「コマンド対策」です。ls、curl、rm等のコマンドや、セミコロン・パイプ文字がシェルインジェクションと誤認されます。

WAF設定項目一覧

Xserverのサーバーパネルで設定できるWAF項目は以下の6つです。

なぜ技術記事で誤検知が起きるのか

技術ブログの記事本文には、上記の検知対象となる文字列がそのまま含まれることが多いのが問題です。シェルコマンドの解説記事ではcd、ls、rm、curlが登場し、.htaccessの設定方法ではファイル名自体が地雷になります。PHPのセッション管理解説ではsession_start()が、SQLクエリの書き方ではSELECTやINSERTが避けられません。

これらは技術記事として当然必要な内容ですが、WAFから見ると「攻撃のためのコード入力」と区別がつかないのです。

典型的な症状パターン3選

501エラーの症状は「特定の記事だけ更新できない（パターンA）」「更新ボタンだけ501（パターンB）」「サイト全体が501（パターンC）」の3つに分類でき、最も多いのはパターンAです。自分がどのパターンか判別することで、原因特定の時間を大幅に短縮できます。

パターンA：特定の記事だけ更新できない（最も多い）

他の記事は普通に投稿・更新できるのに、特定の記事だけ501エラーになるパターンです。その記事本文中の特定の文字列がWAFに引っかかっている可能性が高く、特にコードサンプルやコマンド例を多く含む技術記事で発生しやすい傾向があります。

パターンB：更新・公開・プレビューのみ501

wp-adminの編集画面自体は開けるのに、「更新」「公開」「プレビュー」ボタンを押すと501エラーになるパターンです。編集画面を開く操作（GETリクエスト）は通るが、更新を送信する操作（POSTリクエスト）がブロックされていることを示唆しています。

パターンC：サイト全体が501

管理画面だけでなくサイト全体が501エラーになる場合は、広告タグの自動最適化スクリプト、外部解析ツールのスクリプト、CDNやキャッシュプラグインとの相互作用など、より広範囲の問題が考えられます。アクセスログの確認と、最近追加した外部スクリプトの確認が必要です。

切り分け手順：最短で原因を特定する方法

最も重要なのは「WAFが原因かどうか」を最初に確認することです。別の記事で更新テスト→問題記事のコード部分を削除してテスト→WAF「コマンド対策」のみをOFFにしてテスト——この3ステップで原因が確定します。

ステップ1：別の記事で更新を試す

問題が起きている記事とは別の記事（コードを含まないシンプルな記事）の更新を試みます。別の記事が更新できれば、特定の記事の本文内容が原因の可能性が高いです。別の記事も更新できなければ、サイト全体の問題としてWAF以外の原因も疑います。

ステップ2：問題の記事の本文を短くして試す

問題の記事を開き、本文のコード部分をごっそり削除してから更新を試みます。更新できれば、削除した部分にWAFのトリガーとなる文字列があります。

ステップ3：WAFの「コマンド対策」をOFFにして試す

Xserverサーバーパネルで「コマンド対策」だけを一時的にOFFにしてから更新を試みます。いきなり全部OFFにしないでください。まずは「コマンド対策」のみをOFFにして確認します。これが最も誤検知が多い項目です。

WAF設定の反映遅延に注意

XserverのWAF設定は、変更してもすぐには反映されません。複数の体験談によると、WAF設定の反映には最大1時間程度かかる場合があります。設定変更後すぐにテストして「変わらない」と判断しないでください。これが原因で「設定を変えたのに直らない」と混乱する方が非常に多いです。

キャッシュの影響を排除する

WAF設定を変更しても効果がないように見える場合、キャッシュが原因のことがあります。シークレットウィンドウ（プライベートブラウジング）で試す、ブラウザのキャッシュを完全にクリアする、WordPress側のキャッシュ系プラグインを一時停止する、Cloudflare等のCDNキャッシュもパージする——これらを徹底してください。

キャッシュが原因で「CSS更新が反映されない」問題とも共通するトラブルです。キャッシュの5層構造について詳しくは「CSSキャッシュ5層の切り分けとfilemtimeで二度と揉めない運用」をご覧ください。

誤検知しやすいWAF項目と”地雷ワード”一覧

技術記事でWAFに引っかかりやすい「地雷ワード」を項目別に整理しました。最も危険なのはコマンド対策で、cd・ls・rm・curlのような短いコマンド名がシェルインジェクションと誤認されます。セキュリティ解説記事は攻撃手法そのものを掲載するため、複数のWAF項目に同時に引っかかる”地雷の宝庫”です。

コマンド対策（最も誤検知が多い）

特にcdは非常に短い文字列ですが誤検知の報告が多く、セミコロンとの組み合わせはシェルのコマンド区切りと見なされやすいです。

ファイル対策

.htaccess、.htpasswd、httpd.conf、php.ini、wp-config.phpなどのサーバー設定系ファイル名が検知対象です。.htaccessの設定方法を解説する記事は、ファイル名自体がそのまま地雷ワードになります。

PHP対策

session_start()、$_SESSION、eval()、exec()、system()、shell_exec()、file_get_contents()、file_put_contents()などのPHP関数が検知対象です。プラグイン開発やPHPセキュリティの解説記事で引っかかりやすい項目です。

なお、WordPress.orgのプラグイン審査でもexec()やshell_exec()は指摘対象です。審査の全手順と差し戻し対応については「プラグイン審査に通るまでの実体験：exec削除→承認まで全記録」で詳しく解説しています。

XSS対策・SQL対策

XSS対策では<script>タグ、javascript:スキーム、onerror等のイベントハンドラ、document.cookieが検知対象です。SQL対策ではSELECT、INSERT、UPDATE、DELETE、UNION、DROP TABLE、OR 1=1などの典型的なSQLインジェクションパターンが検知されます。

メール対策

to、cc、bccなどのメールヘッダに関連する文字列が検知対象です。メール送信フォームの解説、PHPのmail()関数の解説、Contact Form 7の設定記事などで引っかかります。

対策A：WAFの該当項目を一時OFFにする（最短復旧）

最短復旧手順は「サーバーパネルでコマンド対策をOFF→反映を最大1時間待つ→シークレットウィンドウで記事更新→即座にONに戻す」です。全項目OFFは避け、コマンド対策のみから試してください。

具体的な手順

Xserverのサーバーパネルにログインし、「セキュリティ」セクションから「WAF設定」を選択します。対象ドメインを選んで「コマンド対策」のみをOFFに変更します。他の項目（XSS対策、SQL対策など）はONのままにしておきます。

設定変更後、反映まで最大1時間程度待ちます。待っている間に、シークレットウィンドウを開いておく、更新したい記事の編集画面を開いておく、キャッシュ系プラグインを一時停止しておくと作業がスムーズです。

反映を待った後、シークレットウィンドウからWordPress管理画面にログインし、問題の記事を更新します。更新が成功したら、必ずWAFの設定をONに戻してください。

この方法の注意点

WAFをOFFにしている間はセキュリティが低下するため、作業時間は最小限に抑えてください。同じ記事を再度編集する際は再びこの手順が必要になります。頻繁に技術記事を書く場合は、次の「対策B：コードの外出し」を検討してください。

対策B：コードを外出しにする（再発防止の本命）

WAFが検査するのは「WordPressへ送信されるPOSTリクエストの本文」です。地雷ワードがWordPress管理画面を経由しないようにすることで誤検知を根本的に回避できます。GitHub Gist、ダウンロードファイル、スクリーンショット画像の3つが現実的な外出し方法です。

方法1：GitHub GistやGitHubリポジトリを活用

コードサンプルをGitHub Gistに置き、記事からはリンクや埋め込みで紹介する方法です。シンタックスハイライトが自動適用され、コードの更新が記事本体と独立して行え、読者がそのままフォーク・クローンできるメリットがあります。

方法2：ダウンロードファイル（ZIP/TXT）として添付

長いコードや設定ファイルはZIPやTXT形式でダウンロードできるようにし、記事本文には要点のみを記載します。WordPressのメディアライブラリにアップロードしてダウンロードリンクを挿入するだけです。

方法3：画像（スクリーンショット）で提示

重要な設定内容やコマンドをテキストではなく画像として掲載する方法です。WAFに検知されず、実際の画面と同じ見た目で伝えられます。ただし読者がコピペできないため、外部リンクも併用してください。

外出し運用のコツ

記事本文には「何をするコードか」の説明と重要なポイントだけを記載し、完全なコードは外部リソースへ誘導します。この運用はWAF対策だけでなく、記事の可読性向上にもつながります。長大なコードブロックで記事が埋め尽くされるよりも、要点を絞った解説のほうが読者にとっても親切です。

対策C：危険な表記を避ける（読者の安全も守る）

技術ブログの社会的責任として、実行可能な攻撃コードの完成形は掲載すべきではありません。コマンドは1行ずつ分割して説明を加え、破壊的操作には警告文を併記し、SQLインジェクションの例は一部を伏せ字にする——これらの工夫は結果的にWAFの誤検知も減らします。

危険なrm -rf /のようなコマンドは概念説明に留め、具体的なパスを伏せます。複数コマンドをセミコロンや&&で連結したワンライナーは各コマンドを分割して1行ずつ説明を加えます。SQLインジェクションやXSSの解説記事でも、実際に動作する攻撃コードの完成形は避け、攻撃の原理を文章で説明するか一部を伏せ字にしてください。

対策D：管理画面の入口を堅くする（WAF一時OFF時の防御補完）

WAFを一時OFFにすることに不安がある場合は、管理画面へのアクセス自体を制限してセキュリティを補完します。IP制限、Basic認証、二要素認証（2FA）、ログインURL変更の4つを組み合わせれば、WAF一時OFF中のリスクを最小限に抑えられます。

管理画面（/wp-admin/やwp-login.php）へのIP制限は、.htaccessまたはXserverのアクセス制限機能で設定できます。Basic認証を追加すれば二重のパスワード保護になり、ブルートフォース攻撃も軽減できます。

二要素認証（2FA）はGoogle AuthenticatorやWordfence Securityプラグインで導入可能です。ログインURLの変更はWPS Hide Loginプラグインで対応できますが、変更後のURLを忘れるとログインできなくなるため注意してください。

なお、Xserverには「REST APIアクセス制限」機能もあります。この設定が有効になっていると、REST APIを使うプラグイン（AIチャットボット等）が動作しなくなる場合があります。詳しくは「XserverでWebSocketもSSEも動かない｜Long Polling実装」で共用レンタルサーバーの制限と対策を解説しています。

それでも直らない場合のトラブルシューティング

WAF設定を変更しても501エラーが解消しない場合は、Xserverのアクセスログで発生時刻のリクエストを確認し、WordPress側のdebug.logでPHPエラーとの切り分けを行います。debug.logにエラーが記録されていなければWAFブロックの可能性が高く、PHPエラーが記録されていればプラグインやテーマの問題です。

アクセスログで詳細を確認

サーバーパネル → 「アクセス解析」または「ログファイル」で、エラーが発生した日時のログを確認します。リクエストURL（/wp-admin/post.phpやadmin-ajax.php）、HTTPステータスコード、リクエスト元IPを確認してください。

WordPressのデバッグログを確認

wp-config.phpに以下を追記してデバッグログを有効化します。

/wp-content/debug.logにエラーが記録されていなければWAFによるブロックの可能性が高く、PHPエラーが記録されていればプラグインやテーマ側の問題です。

WP_DEBUGの設定やデバッグの手法は「WordPress関数一覧まとめ【Part3】Ajax・REST API・セキュリティ設計ガイド」のデバッグセクションで詳しく解説しています。

外部スクリプトが原因の可能性

記事本文以外に、サイト全体に埋め込まれているスクリプトがWAFに引っかかっている可能性もあります。最近追加した広告タグ（Google AdSense、アフィリエイトタグ）、解析ツール（ヒートマップ等）、チャットボットやポップアップ系スクリプトを一時的に無効化して確認してください。

Xserverサポートへの相談テンプレート

上記の対策をすべて試しても解決しない場合はXserverサポートに相談してください。「WAF誤検知」という仮説を明示し、自分で試したこと（コマンド対策OFFで改善等）を伝え、発生日時を具体的に記載することで、サポートの対応が大幅にスムーズになります。

再発防止チェックリスト

「まず復旧」のための最短手順と「再発させない」ための運用ルールを、チェックリスト形式で整理しました。このリストをブックマークしておけば、次回同じエラーが発生しても5分で対応方針を決められます。

最短復旧チェックリスト

再発防止チェックリスト

まとめ

WordPressのコード付き記事で発生する501エラーの原因は、XserverのWAFによる誤検知です。「コマンド対策の一時OFF→記事更新→即ONに戻す」が最短復旧、「コードの外出し運用」が恒久対策、「管理画面のセキュリティ強化」がリスク補完——この3段構えで501エラーに悩まされなくなります。

Xserverで技術ブログを運営する場合、WP-Cronの遅延問題もよくあるトラブルです。「WP-Cronが動かない｜Xserverのcronで時間通りのメール送信を取り戻した話」でXserver固有の対処法を解説しています。