WordPressで
PHPや
Bashスクリプトを含む記事を書いて、「公開」または「更新」を押した瞬間――
XserverのWAF誤検知に引っかかって投稿が通らない。しかも出方がややこしくて、
- 501 Not Implemented が出る
- あるいは、Xserverの案内ページで「WordPress管理画面へのアクセスが拒否されました」と出る
…と、
記事の内容によって症状が変わることがありました（これが本当に厄介）。
以前、同じテーマで「WAF誤検知でコード記事が上がらない」件を書いたのですが、今回さらに試していて、決定的に救われたのが
MarsEditでした。
ブラウザ（WP管理画面）からだと落ちる記事が、MarsEdit経由だと同じ内容でも通った
この記事では、実体験をベースに「なぜ起きるのか」「MarsEditがなぜ効いたのか（推測）」「MarsEditの使い方」「Setappに入っている便利さ」そして今回の追加テーマとして、
XML-RPCを使うなら”IPホワイトリスト”で安全運用すると安心という話まで、読み物としても実用としても役立つ形でまとめます。
先に結論（今日持ち帰ってほしい3点）
コード記事がWAFに刺さるなら投稿ルートを変えるのが早く、XML-RPCを使うならXserver側のIPホワイトリストで入口を絞るのが安心です。
- コード記事がWAFに刺さるなら、投稿ルートを変えるのが早い（私の環境ではMarsEditが効いた）
- MarsEditがXML-RPCを使うなら、Xserver側でXML-RPCを制限し、ホワイトリストに自分のIPだけ登録すると安心
- アプリケーションパスワードが使えない（例：Wordfenceで無効化）場合でも、運用の逃げ道はある（ただし安全対策は厚めに）
1. 私の環境で起きた症状（再現しやすい条件）
PHPコードやBashコマンドを含む記事をブラウザから更新すると、501エラーまたはアクセス拒否が出ます。エディターの種類は関係なく、記事の内容で発生条件が変わりました。
落ちやすかったもの
- PHPコード（危険判定されやすい単語が混ざると落ちやすい体感）
- Bashコマンド（短いコマンドの羅列、削除系・権限系の説明が増えると落ちやすい体感）
エディター
- ブロックエディターでもクラシックでも発生（＝エディター依存ではなかった）
出たエラー
- 501 Not Implemented
- 「WordPress管理画面へのアクセスが拒否されました」（Xserverの案内ページ）
ここがつらいのは、エラーが「WordPressのエラーっぽく見える」こと。
実際にはサーバー側（WAFやセキュリティ設定）が絡んでいる可能性が高いのに、WordPress側のプラグインやテーマを疑って延々と遠回りしがちです。
2. そもそも何が起きてる？：WAFの「コマンド対策」がコードの単語に反応しやすい
WAFは通信の”文脈”を理解しません。ブログ記事としてのコード紹介と、攻撃者によるコマンド送信の区別がつかず、誤検知が起きます。
WAFはWeb攻撃を防ぐための仕組みで、ざっくり言うと「怪しい通信を止める門番」です。
ただし門番は”文脈”を理解しません。つまり、
- あなた：ブログ記事としてコマンドを紹介している
- WAF：攻撃者がコマンドを送り込んでいるかもしれない
このすれ違いが起きます。
特に
シェルの説明記事は「攻撃パターンと似た文字列」が多く、誤検知しやすい構造になりがちです。
さらにややこしいのが、WordPressの投稿は「本文を保存する」だけではなく、裏側でいくつかの処理が動く点。
例えば、ブロックエディターだと保存時にREST APIの通信が混ざることがありますし、セキュリティ系プラグインが介入すると追加の検査が入ることもあります。
その結果「投稿ボタンを押した瞬間に落ちる」という、書き手にとって最悪の体験が発生します。
3. なぜ「アクセス拒否」ページまで出るの？（混乱ポイント）
501エラーとは別に、Xserverの「WordPress管理画面へのアクセス拒否」が出ることがあります。WAFの判定・セキュリティ設定・投稿経路が絡み合って症状がブレるのが厄介です。
「501」はまだ分かりやすいのですが、ややこしいのが
“WordPress管理画面へのアクセス拒否”という別の表示が出ること。
このタイプの画面は、Xserver側の
WordPressセキュリティ設定（国外アクセス制限、REST APIやXML-RPCの制限など）と絡んで出ることがあります。
体感としては、WAFの判定・セキュリティ設定・投稿経路（管理画面/RESTなど）が噛み合って、同じサイトでも症状の出方がブレる――そんな挙動でした（※ここはあくまで推測です）。
読者が一番困るのは「結局、どこを触ればいいの？」状態になること。だからこそ、次の章で
私が効果を感じた”切り替え策”を書きます。
4. そこで救世主：MarsEditで投稿したら、同じ記事が通った
ブラウザから落ちる記事が、MarsEditから投稿すると同じ内容でも通りました。書き方を変えずに済むのが最大のメリットです。
色々試す中で「投稿経路を変えたらどうなる？」と思って使ったのが、Mac用ブログエディタ
MarsEditです。
- 管理画面から投稿 → 落ちる
- MarsEditから投稿 → 通る
これが大きかったのは、「書き方を変えずに済む」点です。
WAF誤検知を避けるために、コードを変な書き方にしたり、危険語を全部エスケープしたり……をやり始めると、記事の読みやすさが崩れます。
でもMarsEditなら、
“いつものコード解説のまま”公開まで持っていけました。
5. なぜMarsEditだと通ったのか（推測：投稿ルートの違い）
ブラウザはREST API/AJAX、MarsEditはXML-RPCと、通信経路が異なります。WAFの”当たり判定ポイント”が違うことで、同じ本文でも結果が変わったと推測しています。
ここからは「確定」ではなく
推測ですが、挙動としては筋が通っています。
- ブラウザ投稿：WordPress管理画面がREST API / AJAXなど複数の通信を使う
- MarsEdit投稿：多くの場合、XML-RPC（xmlrpc.php）を使う
つまり、
WAFやセキュリティ設定の”当たり判定ポイント”が違う可能性がある、という話です。
同じ本文でも「どこにどう送るか」で判定が変わる――これが今回の”抜け道”になったのだと思っています。
ここで大事なのは、MarsEditが「魔法の回避ツール」ではなく、
通信の経路が違うことで結果が変わった、という点。
だからこそ次章の「安全運用」が重要になります。
6. MarsEditの便利さ（WAF回避以外にも、普通に執筆がラク）
MarsEditはWAF回避だけでなく、ローカル執筆・高速プレビュー・下書き管理など、日常の執筆体験そのものを改善してくれるツールです。
- ローカルで書ける（ブラウザの重さ／誤操作／編集中の通信落ちから解放）
- 下書きが資産になる（再編集、別記事への転用がしやすい）
- プレビューが速い（確認ストレスが減る）
- タグ・カテゴリ・抜粋などの設定がまとまっていて迷いにくい
ブログって、結局「書く時間」より「詰まる時間」に体力を削られます。
MarsEditは、その詰まりを減らしてくれる道具でした。
7. Setappに入っているのが地味に強い
MarsEditはSetappに含まれているため、すでにSetappを使っていれば追加コストなしで試せます。
個人的に嬉しかったのが、MarsEditが
Setappに入っていること。
普段からSetappを使っているなら、追加コストなしで「とりあえず試す」ができます。
8. MarsEdit × WordPress 接続の基本（ここで詰まりやすいポイントも含めて）
接続自体は簡単ですが、認証とセキュリティ設定で詰まりやすいです。理想はアプリケーションパスワードですが、Wordfenceが無効化しているケースがあります。
- MarsEditを起動
- ブログ（WordPressサイト）を追加
- サイトURL、ユーザー名、認証情報を入力して接続
- 記事を書いて、プレビューして、投稿
ここで詰まりやすいのが「認証」と「セキュリティ設定」です。
理想は
アプリケーションパスワードですが、あなたの環境のように
Wordfenceが無効化しているケースがあります。
9. アプリケーションパスワードが使えない（Wordfenceで無効化）ときの現実的な選択肢
アプリケーションパスワードが使えない場合でも、専用ユーザー＋最小権限＋強固なパスワード＋XML-RPC IP制限の組み合わせで、安全に運用できます。
まず前提として、外部アプリ連携は「通常のログイン」と違い、
機械的に認証情報を渡すので、どうしてもリスクが増えます。
だから「使えないなら諦める」ではなく、
代わりに守りを厚くする方向で考えるのが現実的です。
選択肢A：Wordfence側で”アプリケーションパスワード無効化”を解除できるなら（推奨）
もし運用ポリシー的にOKなら、Wordfenceの設定でアプリケーションパスワードを許可できる場合があります。
一般にWordfenceには「Disable WordPress application passwords」のような項目があり、ここを無効にするとアプリケーションパスワードが使える構成に戻せることがあります。
この方法の良いところは、
普段のログイン用パスワードを外部アプリに渡さずに済む点。
「必要なときだけ作って、不要になったら無効化できる」のが強いです。
選択肢B：どうしてもアプリケーションパスワードが使えないなら
この場合、MarsEdit側は通常のユーザー名＋パスワードで認証する形になりやすいです。
だからこそ、次の”防御の重ね掛け”が重要になります。
- 専用ユーザーを作る（普段の管理者と分ける）
- 権限は最小に（投稿だけなら「投稿者」など。必要に応じて）
- パスワードは強固に（使い回し禁止、長いランダム推奨）
- XML-RPCはIP制限（ホワイトリスト）で入口を絞る
- Wordfenceのログイン保護/試行回数制限は強めに
ここまでやると、「外部アプリ連携を許可しつつ、入口を狭める」形に近づきます。
10. ここがこの記事の核心：XML-RPCは「Xserver側でIPホワイトリスト運用」が安心
MarsEditがXML-RPCを使う構成なら、Xserverの「XML-RPC APIアクセス制限」＋「ホワイトリスト」で自分のIPだけ許可する運用が最も安心です。
MarsEditがXML-RPCを使う構成になるなら、セキュリティ的には
入口（xmlrpc.php）を守りたくなります。
そこでおすすめなのが、Xserverの
WordPressセキュリティ設定にある
XML-RPC APIアクセス制限と
ホワイトリストの併用です。
10-1. 何ができる？（イメージ）
- XML-RPCへのアクセスを「基本はブロック」
- ただしホワイトリストに登録したIPだけは「例外的に許可」
つまり、
自分のIPからのMarsEdit投稿だけ通す運用ができます。
10-2. 設定手順（Xserverサーバーパネル側）
- Xserverのサーバーパネルにログイン
- 「WordPress」系メニューからWordPressセキュリティ設定を開く
- 対象ドメインを選択
- XML-RPC APIアクセス制限を確認
- ホワイトリストを開き、自分のIPアドレスを1行1つで登録
【スクショ⑦をここに（必須級）】
（Xserver「WordPressセキュリティ設定」画面。XML-RPCの項目とホワイトリスト編集が分かるところ）
10-3. 「自分のIPアドレス」ってどれ？
基本は「いま自分がインターネットに出ていく出口のIP」です。
検索で
「自分のIPアドレス 確認」 と打てば確認サイトが出ます。
注意点として、
- IPv4とIPv6の両方が出る環境がある
- ホワイトリストがどちらに対応しているかで、登録すべき値が変わる
…という点があります。迷ったら、まずは
普段投稿するときの回線で確認し、そのIPを登録して動作確認するのが確実です。
10-4. 注意：IPが変わる環境だと、投稿できなくなる
- 自宅回線でも、契約やルーター再起動でIPが変わることがあります
- 外出先のWi-Fi、テザリング、VPNは特に変わりやすいです
つまり、ホワイトリスト運用は
「その場所（回線）からの投稿に限定する」のと同義です。
逆に言えば、
投稿環境が固定できる人ほど強い運用です。
私は「普段は自宅から投稿」「出先でどうしても必要なときだけ、その場のIPを一時的に追加→終わったら削除」みたいな運用にしています。
11. それでもブラウザ投稿を通したい人向け：記事の”壊し方”を減らす小ワザ
MarsEditが使えない環境では、ゼロ幅スペースの挿入やコマンドの画像化で誤検知を減らせますが、これは最後の手段です。
本当は「ブラウザからも普通に更新できる」が理想です。
ただ、現実にWAF誤検知が強い環境では、更新のたびに詰まります。そこで小ワザとして、本文の”危険語”を
読者に伝わる形で分散させる方法があります。
- 単語の途中にゼロ幅スペースを挟む（見た目は同じでもWAFが拾いにくい場合がある）
- コマンドや危険語を画像にして添付し、本文は通常文中心にする
- 「危険語の説明」パートだけ別記事にしてリンクする（運用で分散）
ただしこれは”最後の手段”です。記事としての読みやすさが落ちたり、検索性が下がることがあります。
今回の主役はあくまで、
MarsEditで投稿経路を変えて、文章の自然さを守ることです。
12. トラブルシュート：MarsEditが投稿できないときのチェックリスト
投稿できないときは、ホワイトリストのIPズレ、WordfenceによるXML-RPCブロック、ユーザー権限不足の3つを最初に確認してください。
- XML-RPCを制限しすぎていないか（ホワイトリストにIPが入っているか／IPが変わっていないか）
- WordfenceがXML-RPC自体をブロックしていないか（設定・ログを確認）
- 専用ユーザーの権限が足りるか（下書き/公開の可否）
- Cloudflare等の外部サービスを経由している場合、出口IPが想定とズレることがある（IP制限と相性チェック）
まとめ
コード系ブログでWAF誤検知に悩むなら、MarsEditで投稿経路を2本化し、XML-RPCはXserverのIPホワイトリストで入口を絞る。この構成で「更新ボタンが怖い」状態から抜けられます。
ブラウザ投稿がWAFに刺さると、
発信が止まるのが一番痛い。
だから私は、
- 普段は管理画面で整える（装飾・画像・細かい設定）
- 詰まったらMarsEditで投稿だけ通す（WAF誤検知に負けない）
- MarsEditがXML-RPCを使うなら、XserverのXML-RPC制限＋IPホワイトリストで入口を絞る
- さらに、アプリケーションパスワードが使えないなら、専用ユーザー＋最小権限＋強固なパスワードで守りを厚くする
この運用にしてから、「更新ボタンが怖い」状態から抜けられました。
コード記事を書き続けるなら、MarsEditは”文章を書く道具”というより、
公開まで持ち込むための保険として効きます。
参考リンク
この記事で参照したドキュメントの一覧です。
- MarsEditヘルプ（接続トラブル）：https://help.redsweater.com/marsedit/common-connection-problems/
- WordPressコア：アプリケーションパスワード統合ガイド：https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/
- Wordfence：Brute Force Protection：https://www.wordfence.com/help/firewall/brute-force/
コメント