検証環境：WordPress 6.9.4 / Xserver スタンダードプラン / PHP 8.3.21 / MarsEdit 5.3.12（2026年3月時点）
「WordPressで技術記事を投稿しようとしたら、突然501 Not Implementedエラーが出て更新できない！」
技術ブログを運営していると、一度はぶつかるこのトラブル。特にPHPやJavaScript、シェルコマンドなどのコードサンプルを含む記事を書いているときに頻発します。
この問題の原因の多くはXserverのWAF（Web Application Firewall）が記事本文中の文字列を攻撃と誤認してブロックしていることにあります。WordPress自体が壊れたわけではありません。
この記事では、501エラーの「今すぐ復旧したい」という緊急対応から、「二度と同じ目に遭いたくない」という再発防止策、さらに「MarsEditで投稿経路を変えて回避した」実体験まで、すべてを網羅した完全ガイドをお届けします。
原因：WAFがPOST本文を攻撃と誤認している
WordPressの記事投稿はPOSTメソッドで行われますが、XserverのWAFが記事本文中のコード（ls、curl、SELECT等）を攻撃パターンとして検知し、リクエストをブロックした結果として501エラーが表示されます。あなたが変なHTTPメソッドを送ったわけではありません。
エラー発生の流れは以下の通りです。WordPressから記事更新のPOSTリクエストが送信され、XserverのWAFがリクエスト本文（記事内容）をスキャンします。本文中の特定文字列が「攻撃パターン」としてマッチし、WAFがリクエストをブロック。その結果、Xserver側の汎用エラーページ（501）が返されます。
WAFは通信の「文脈」を理解しません。ブログ記事としてのコード紹介と、攻撃者によるコマンド送信の区別がつかないため、誤検知が起きます。実際、複数の事例報告でWAFの「コマンド対策」をOFFにすると501エラーが解消したことが確認されています。
501 Not Implementedの技術的背景
HTTP仕様（RFC 9110）では501はサーバーがリクエストメソッドを実装していない場合に返すステータスコードですが、Xserverでの501エラーはWAFブロックの副産物であり、本来の意味とは異なります。WordPress操作中にこのエラーが出たらWAFを疑ってください。
本来はWebDAVのMOVEやCOPYといった特殊メソッドを非対応サーバーに送った場合に返されるエラーです。WordPressの通常操作ではこれらのメソッドは使用されません。したがって、WordPress操作中に501エラーが出た場合は「WAFがリクエストをブロックし、その結果として501エラーページが表示されている」と解釈するのが正確です。
XserverのWAFの仕組みと誤検知の理由
XserverのWAFにはXSS対策・SQL対策・ファイル対策・メール対策・コマンド対策・PHP対策の6項目があり、技術ブログで最も誤検知が多いのは「コマンド対策」です。ls、curl、rm等のコマンドや、セミコロン・パイプ文字がシェルインジェクションと誤認されます。
| 項目名 | 検知対象 |
|---|---|
| XSS対策 | scriptタグ等、JavaScript実行に関連する文字列 |
| SQL対策 | SQL構文（SELECT、INSERT、DELETE等） |
| ファイル対策 | .htaccess、httpd.conf等のサーバー設定系ファイル名 |
| メール対策 | to、cc、bcc等のメールヘッダに関連する文字列 |
| コマンド対策 | kill、ftp、mail、ping、ls等のコマンドに関連する文字列 |
| PHP対策 | session、ファイル操作関連、危険度の高い関数等 |
典型的な症状パターン
501エラーの症状は「特定の記事だけ更新できない（パターンA）」「更新ボタンだけ501（パターンB）」「管理画面アクセス拒否（パターンC）」「サイト全体が501（パターンD）」の4つに分類でき、最も多いのはパターンAです。
パターンA：特定の記事だけ更新できない（最も多い）。他の記事は普通に投稿・更新できるのに、特定の記事だけ501エラーになります。コードサンプルやコマンド例を多く含む技術記事で発生しやすい傾向があります。
パターンB：更新・公開・プレビューのみ501。編集画面自体は開けるのに、「更新」「公開」ボタンを押すと501エラーになります。GET（画面表示）は通るがPOST（送信）がブロックされている状態です。
パターンC：「管理画面へのアクセスが拒否されました」と表示される。501とは別に、Xserverの案内ページで「WordPress管理画面へのアクセスが拒否されました」と表示されるケースがあります。WAFの判定とXserverのWordPressセキュリティ設定（国外アクセス制限、REST API制限等）が絡み合って出る症状で、記事の内容によって501と「アクセス拒否」のどちらが出るかが変わるのが厄介です。
パターンD：サイト全体が501。管理画面だけでなくサイト全体が501エラーになる場合は、広告タグや外部解析ツールのスクリプトなど、より広範囲の問題が考えられます。
切り分け手順：最短で原因を特定する方法
最も重要なのは「WAFが原因かどうか」を最初に確認することです。別の記事で更新テスト→問題記事のコード部分を削除してテスト→WAF「コマンド対策」のみをOFFにしてテスト——この3ステップで原因が確定します。
ステップ1：別の記事で更新を試す。コードを含まないシンプルな記事の更新を試みます。別の記事が更新できれば、特定の記事の本文内容が原因の可能性が高いです。
ステップ2：問題の記事の本文を短くして試す。コード部分をごっそり削除してから更新を試みます。更新できれば、削除した部分にWAFのトリガーがあります。
ステップ3：WAFの「コマンド対策」をOFFにして試す。Xserverサーバーパネルで「コマンド対策」だけを一時的にOFFにします。いきなり全部OFFにしないでください。
誤検知しやすい「地雷ワード」一覧
技術記事でWAFに引っかかりやすい「地雷ワード」を項目別に整理しました。最も危険なのはコマンド対策で、cd・ls・rm・curlのような短いコマンド名がシェルインジェクションと誤認されます。
| WAF項目 | 地雷ワード |
|---|---|
| コマンド対策（最多） | cd ls rm mv cp curl wget ssh kill | ; && |
| ファイル対策 | .htaccess .htpasswd httpd.conf php.ini wp-config.php |
| PHP対策 | session_start() eval() exec() shell_exec() file_get_contents() |
| XSS対策 | <script> javascript: onerror document.cookie |
| SQL対策 | SELECT INSERT UPDATE DELETE UNION DROP TABLE OR 1=1 |
| メール対策 | to cc bcc（メールヘッダ関連）、mail()関数 |
対策A：WAFの該当項目を一時OFFにする（最短復旧）
最短復旧手順は「サーバーパネルでコマンド対策をOFF→反映を最大1時間待つ→シークレットウィンドウで記事更新→即座にONに戻す」です。全項目OFFは避け、コマンド対策のみから試してください。
Xserverのサーバーパネル → セキュリティ → WAF設定 → 対象ドメイン → 「コマンド対策」のみをOFFに変更します。反映を待った後、シークレットウィンドウから管理画面にログインして記事を更新します。更新が成功したら必ずWAFをONに戻してください。
WAFをOFFにしている間はセキュリティが低下するため、作業時間は最小限に抑えてください。頻繁に技術記事を書く場合は、次の「対策B：コードの外出し」か「対策E：MarsEditで投稿経路を変える」を検討してください。
対策B：コードを外出しにする（再発防止の本命）
WAFが検査するのは「WordPressへ送信されるPOSTリクエストの本文」です。地雷ワードがWordPress管理画面を経由しないようにすることで誤検知を根本的に回避できます。GitHub Gist、ダウンロードファイル、スクリーンショット画像の3つが現実的な外出し方法です。
方法1：GitHub GistやGitHubリポジトリを活用。コードサンプルをGitHub Gistに置き、記事からはリンクや埋め込みで紹介します。シンタックスハイライトが自動適用され、コードの更新が記事本体と独立して行えます。
方法2：ダウンロードファイル（ZIP/TXT）として添付。長いコードや設定ファイルはZIPやTXT形式でダウンロードできるようにし、記事本文には要点のみを記載します。
方法3：画像（スクリーンショット）で提示。重要な設定内容やコマンドを画像として掲載します。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のアクセス制限機能で設定できます。二要素認証（2FA）はWordfence Securityプラグインで導入可能です。
対策E：MarsEditで投稿経路を変える（実体験）
ブラウザ（WordPress管理画面）から落ちる記事が、MarsEdit経由だと同じ内容でも通りました。ブラウザはREST API/AJAXを使い、MarsEditはXML-RPCを使うため、WAFの判定ポイントが異なることが原因と推測しています。「書き方を変えずに済む」のが最大のメリットです。
色々試す中で「投稿経路を変えたらどうなる？」と思って使ったのが、Mac用ブログエディタMarsEditです。
- 管理画面から投稿 → 落ちる
- MarsEditから投稿 → 通る
これが大きかったのは「書き方を変えずに済む」点です。WAF誤検知を避けるためにコードを変な書き方にしたり、危険語を全部エスケープすると記事の読みやすさが崩れます。MarsEditなら、いつものコード解説のまま公開まで持っていけました。
なぜMarsEditだと通るのか（推測）
ブラウザ投稿はREST API / AJAXなど複数の通信を使いますが、MarsEditはXML-RPC（xmlrpc.php）を使います。WAFやセキュリティ設定の判定ポイントが違うため、同じ本文でも「どこにどう送るか」で結果が変わったと推測しています。
MarsEditはWAF回避だけでなく、ローカルで書ける（ブラウザの重さや誤操作から解放）、下書きが資産になる、プレビューが速いなど日常の執筆体験そのものを改善してくれます。Setappに含まれているため、すでにSetappを使っていれば追加コストなしで試せます。
XML-RPCを使うならIPホワイトリストで入口を絞る
MarsEditがXML-RPCを使う構成なら、Xserverの「XML-RPC APIアクセス制限」＋「ホワイトリスト」で自分のIPだけ許可する運用が安心です。
Xserverサーバーパネル → WordPressセキュリティ設定 → XML-RPC APIアクセス制限 → ホワイトリストに自分のIPアドレスを登録します。
注意点として、自宅回線でもルーター再起動でIPが変わることがあります。ホワイトリスト運用は「その場所からの投稿に限定する」のと同義です。投稿環境が固定できる人ほど強い運用です。
アプリケーションパスワードが使えない場合
MarsEditの認証は理想的にはアプリケーションパスワードですが、WordfenceがApplication Passwordsを無効化しているケースがあります。その場合は、MarsEdit専用ユーザーを作成して権限は「投稿者」（最小限）に設定し、パスワードは強固なランダム文字列を使い、XML-RPCはIP制限で入口を絞る——この組み合わせで安全に運用できます。
MarsEditが投稿できないときのチェックリスト
ホワイトリストのIPがズレていないか、WordfenceがXML-RPC自体をブロックしていないか、専用ユーザーの権限が足りるか（下書き/公開の可否）、Cloudflare等を経由している場合は出口IPが想定とズレていないか——この4点を確認してください。
それでも直らない場合のトラブルシューティング
WAF設定を変更しても501エラーが解消しない場合は、Xserverのアクセスログで発生時刻のリクエストを確認し、WordPress側のdebug.logでPHPエラーとの切り分けを行います。debug.logにエラーが記録されていなければWAFブロックの可能性が高く、PHPエラーが記録されていればプラグインやテーマの問題です。
wp-config.phpに以下を追記してデバッグログを有効化します。
|
1 2 3 |
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); |
/wp-content/debug.logにエラーが記録されていなければWAFによるブロックの可能性が高く、PHPエラーが記録されていればプラグインやテーマ側の問題です。
Xserverサポートへの相談テンプレート
上記の対策をすべて試しても解決しない場合はXserverサポートに相談してください。「WAF誤検知」という仮説を明示し、自分で試したこと（コマンド対策OFFで改善等）を伝え、発生日時を具体的に記載することで、サポートの対応が大幅にスムーズになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
件名：WAF誤検知と思われる501 Not Implementedについて お世話になっております。 ◯◯ドメイン（example.com）でWordPressを運用しております。 記事の投稿・更新時に501 Not Implementedエラーが発生します。 【症状】 ・特定の記事（コード・コマンド例を含む）で再現 ・他の記事は正常に更新可能 ・WAF「コマンド対策」をOFFにすると改善 【発生日時】YYYY/MM/DD HH:MM頃（JST） WAFの検知ログの確認、原因ルールの特定、 URI単位での除外設定の可否についてご教示ください。 |
再発防止チェックリスト
「まず復旧」のための最短手順と「再発させない」ための運用ルールを、チェックリスト形式で整理しました。
最短復旧
| 順序 | 確認項目 |
|---|---|
| 1 | 別の記事は更新できるか確認した |
| 2 | 問題の記事のコード部分を削ると更新できるか確認した |
| 3 | WAF「コマンド対策」をOFFにして反映を待った（最大1時間） |
| 4 | キャッシュを排除した（シークレットウィンドウ、プラグイン停止等） |
| 5 | 記事の更新が成功した |
| 6 | WAFをONに戻した |
再発防止
| 対策 | 内容 |
|---|---|
| コード外出し | 長いコードはGitHub Gist・添付ファイルに移動した |
| 投稿経路の2本化 | MarsEdit（XML-RPC）で投稿できる環境を用意した |
| XML-RPC防御 | XserverのIPホワイトリストで自分のIPだけ許可した |
| 表記ルール | 危険なコマンドの完成形は本文に置かない運用にした |
| 管理画面防御 | 2FA・IP制限を導入した |
まとめ
WordPressのコード付き記事で発生する501エラーの原因はXserverのWAFによる誤検知です。「コマンド対策の一時OFF」が最短復旧、「コードの外出し」が恒久対策、「MarsEditで投稿経路を2本化」が保険——この3段構えで501エラーに悩まされなくなります。
| 対応フェーズ | やること |
|---|---|
| 緊急対応 | WAFの「コマンド対策」を一時OFFにして記事を更新し、すぐにONに戻す |
| 恒久対策 | コードを外出し（GitHub Gist、添付ファイル等）する運用に切り替える |
| 投稿保険 | MarsEdit（XML-RPC経由）で投稿経路を2本化し、IPホワイトリストで安全運用 |
| 防御強化 | WAF一時OFF時のリスクに備えて、管理画面のセキュリティを強化しておく |
コメント