XserverのWAF誤検知でコード記事が上がらない…MarsEditで投稿した実体験（XML-RPCはIP制限で安全運用）

XserverのWAF誤検知に MarsEditで対処した実体験 WordPress
2026.01.12
この記事は約10分で読めます。
  1. 先に結論（今日持ち帰ってほしい3点）
  2. 1. 私の環境で起きた症状（再現しやすい条件）
    1. 落ちやすかったもの
    2. エディター
    3. 出たエラー
  3. 2. そもそも何が起きてる？：WAFの「コマンド対策」がコードの単語に反応しやすい
  4. 3. なぜ「アクセス拒否」ページまで出るの？（混乱ポイント）
  5. 4. そこで救世主：MarsEditで投稿したら、同じ記事が通った
  6. 5. なぜMarsEditだと通ったのか（推測：投稿ルートの違い）
  7. 6. MarsEditの便利さ（WAF回避以外にも、普通に執筆がラク）
  8. 7. Setappに入っているのが地味に強い
  9. 8. MarsEdit × WordPress 接続の基本（ここで詰まりやすいポイントも含めて）
  10. 9. アプリケーションパスワードが使えない（Wordfenceで無効化）ときの現実的な選択肢
    1. 選択肢A：Wordfence側で“アプリケーションパスワード無効化”を解除できるなら（推奨）
    2. 選択肢B：どうしてもアプリケーションパスワードが使えないなら
  11. 10. ここがこの記事の核心：XML-RPCは「Xserver側でIPホワイトリスト運用」が安心
    1. 10-1. 何ができる？（イメージ）
    2. 10-2. 設定手順（Xserverサーバーパネル側）
    3. 10-3. 「自分のIPアドレス」ってどれ？
    4. 10-4. 注意：IPが変わる環境だと、投稿できなくなる
  12. 11. それでもブラウザ投稿を通したい人向け：記事の“壊し方”を減らす小ワザ
  13. 12. トラブルシュート：MarsEditが投稿できないときのチェックリスト
  14. まとめ：コード系ブログは「執筆経路を2本」＋「XML-RPCはIP制限」で止まらない
  15. 参考リンク（必要なら本文末に）

WordPressでPHPやBashスクリプトを含む記事を書いて、「公開」または「更新」を押した瞬間――
XserverのWAF誤検知に引っかかって投稿が通らない。しかも出方がややこしくて、

  • 501 Not Implemented が出る
  • あるいは、Xserverの案内ページで「WordPress管理画面へのアクセスが拒否されました」と出る

…と、記事の内容によって症状が変わることがありました（これが本当に厄介）。

XserverのWordPress管理画面アクセス拒否の案内

以前、同じテーマで「WAF誤検知でコード記事が上がらない」件を書いたのですが、今回さらに試していて、決定的に救われたのがMarsEditでした。

ブラウザ（WP管理画面）からだと落ちる記事が、MarsEdit経由だと同じ内容でも通った

この記事では、実体験をベースに「なぜ起きるのか」「MarsEditがなぜ効いたのか（推測）」「MarsEditの使い方」「Setappに入っている便利さ」そして今回の追加テーマとして、XML-RPCを使うなら“IPホワイトリスト”で安全運用すると安心という話まで、読み物としても実用としても役立つ形でまとめます。

先に結論（今日持ち帰ってほしい3点）

  1. コード記事がWAFに刺さるなら、投稿ルートを変えるのが早い（私の環境ではMarsEditが効いた）
  2. MarsEditがXML-RPCを使うなら、Xserver側でXML-RPCを制限し、ホワイトリストに自分のIPだけ登録すると安心
  3. アプリケーションパスワードが使えない（例：Wordfenceで無効化）場合でも、運用の逃げ道はある（ただし安全対策は厚めに）

1. 私の環境で起きた症状（再現しやすい条件）

落ちやすかったもの

  • PHPコード（危険判定されやすい単語が混ざると落ちやすい体感）
  • Bashコマンド（短いコマンドの羅列、削除系・権限系の説明が増えると落ちやすい体感）

エディター

  • ブロックエディターでもクラシックでも発生（＝エディター依存ではなかった）

出たエラー

  • 501 Not Implemented
  • 「WordPress管理画面へのアクセスが拒否されました」（Xserverの案内ページ）

WordPress更新時のエラー画面

ここがつらいのは、エラーが「WordPressのエラーっぽく見える」こと。
実際にはサーバー側（WAFやセキュリティ設定）が絡んでいる可能性が高いのに、WordPress側のプラグインやテーマを疑って延々と遠回りしがちです。

2. そもそも何が起きてる？：WAFの「コマンド対策」がコードの単語に反応しやすい

WAFはWeb攻撃を防ぐための仕組みで、ざっくり言うと「怪しい通信を止める門番」です。
ただし門番は“文脈”を理解しません。つまり、

  • あなた：ブログ記事としてコマンドを紹介している
  • WAF：攻撃者がコマンドを送り込んでいるかもしれない

このすれ違いが起きます。
特にシェルの説明記事は「攻撃パターンと似た文字列」が多く、誤検知しやすい構造になりがちです。

さらにややこしいのが、WordPressの投稿は「本文を保存する」だけではなく、裏側でいくつかの処理が動く点。
例えば、ブロックエディターだと保存時にREST APIの通信が混ざることがありますし、セキュリティ系プラグインが介入すると追加の検査が入ることもあります。
その結果「投稿ボタンを押した瞬間に落ちる」という、書き手にとって最悪の体験が発生します。

3. なぜ「アクセス拒否」ページまで出るの？（混乱ポイント）

「501」はまだ分かりやすいのですが、ややこしいのが“WordPress管理画面へのアクセス拒否”という別の表示が出ること。

このタイプの画面は、Xserver側のWordPressセキュリティ設定（国外アクセス制限、REST APIやXML-RPCの制限など）と絡んで出ることがあります。
体感としては、WAFの判定・セキュリティ設定・投稿経路（管理画面/RESTなど）が噛み合って、同じサイトでも症状の出方がブレる――そんな挙動でした（※ここはあくまで推測です）。

読者が一番困るのは「結局、どこを触ればいいの？」状態になること。だからこそ、次の章で私が効果を感じた“切り替え策”を書きます。

4. そこで救世主：MarsEditで投稿したら、同じ記事が通った

色々試す中で「投稿経路を変えたらどうなる？」と思って使ったのが、Mac用ブログエディタMarsEditです。

  • 管理画面から投稿 → 落ちる
  • MarsEditから投稿 → 通る

MarsEditのWordPress投稿画面

MarsEdit経由で公開できた記事の表示

これが大きかったのは、「書き方を変えずに済む」点です。
WAF誤検知を避けるために、コードを変な書き方にしたり、危険語を全部エスケープしたり……をやり始めると、記事の読みやすさが崩れます。
でもMarsEditなら、“いつものコード解説のまま”公開まで持っていけました。

5. なぜMarsEditだと通ったのか（推測：投稿ルートの違い）

ここからは「確定」ではなく推測ですが、挙動としては筋が通っています。

  • ブラウザ投稿：WordPress管理画面がREST API / AJAXなど複数の通信を使う
  • MarsEdit投稿：多くの場合、XML-RPC（xmlrpc.php）を使う

つまり、WAFやセキュリティ設定の“当たり判定ポイント”が違う可能性がある、という話です。
同じ本文でも「どこにどう送るか」で判定が変わる――これが今回の“抜け道”になったのだと思っています。

ここで大事なのは、MarsEditが「魔法の回避ツール」ではなく、通信の経路が違うことで結果が変わった、という点。
だからこそ次章の「安全運用」が重要になります。

6. MarsEditの便利さ（WAF回避以外にも、普通に執筆がラク）

  • ローカルで書ける（ブラウザの重さ／誤操作／編集中の通信落ちから解放）
  • 下書きが資産になる（再編集、別記事への転用がしやすい）
  • プレビューが速い（確認ストレスが減る）
  • タグ・カテゴリ・抜粋などの設定がまとまっていて迷いにくい

ブログって、結局「書く時間」より「詰まる時間」に体力を削られます。
MarsEditは、その詰まりを減らしてくれる道具でした。

7. Setappに入っているのが地味に強い

個人的に嬉しかったのが、MarsEditがSetappに入っていること。
普段からSetappを使っているなら、追加コストなしで「とりあえず試す」ができます。

SetappにMarsEditが含まれている画面

8. MarsEdit × WordPress 接続の基本（ここで詰まりやすいポイントも含めて）

  1. MarsEditを起動
  2. ブログ（WordPressサイト）を追加
  3. サイトURL、ユーザー名、認証情報を入力して接続
  4. 記事を書いて、プレビューして、投稿

ここで詰まりやすいのが「認証」と「セキュリティ設定」です。
理想はアプリケーションパスワードですが、あなたの環境のようにWordfenceが無効化しているケースがあります。

9. アプリケーションパスワードが使えない（Wordfenceで無効化）ときの現実的な選択肢

まず前提として、外部アプリ連携は「通常のログイン」と違い、機械的に認証情報を渡すので、どうしてもリスクが増えます。
だから「使えないなら諦める」ではなく、代わりに守りを厚くする方向で考えるのが現実的です。

選択肢A：Wordfence側で“アプリケーションパスワード無効化”を解除できるなら（推奨）

もし運用ポリシー的にOKなら、Wordfenceの設定でアプリケーションパスワードを許可できる場合があります。
一般にWordfenceには「Disable WordPress application passwords」のような項目があり、ここを無効にするとアプリケーションパスワードが使える構成に戻せることがあります。

XserverのWordPressセキュリティ設定 XML-RPCホワイトリスト

この方法の良いところは、普段のログイン用パスワードを外部アプリに渡さずに済む点。
「必要なときだけ作って、不要になったら無効化できる」のが強いです。

選択肢B：どうしてもアプリケーションパスワードが使えないなら

この場合、MarsEdit側は通常のユーザー名＋パスワードで認証する形になりやすいです。
だからこそ、次の“防御の重ね掛け”が重要になります。

  • 専用ユーザーを作る（普段の管理者と分ける）
  • 権限は最小に（投稿だけなら「投稿者」など。必要に応じて）
  • パスワードは強固に（使い回し禁止、長いランダム推奨）
  • XML-RPCはIP制限（ホワイトリスト）で入口を絞る
  • Wordfenceのログイン保護/試行回数制限は強めに

ここまでやると、「外部アプリ連携を許可しつつ、入口を狭める」形に近づきます。

10. ここがこの記事の核心：XML-RPCは「Xserver側でIPホワイトリスト運用」が安心

MarsEditがXML-RPCを使う構成になるなら、セキュリティ的には入口（xmlrpc.php）を守りたくなります。
そこでおすすめなのが、XserverのWordPressセキュリティ設定にあるXML-RPC APIアクセス制限とホワイトリストの併用です。

10-1. 何ができる？（イメージ）

  • XML-RPCへのアクセスを「基本はブロック」
  • ただしホワイトリストに登録したIPだけは「例外的に許可」

つまり、自分のIPからのMarsEdit投稿だけ通す運用ができます。

10-2. 設定手順（Xserverサーバーパネル側）

  1. Xserverのサーバーパネルにログイン
  2. 「WordPress」系メニューからWordPressセキュリティ設定を開く
  3. 対象ドメインを選択
  4. XML-RPC APIアクセス制限を確認
  5. ホワイトリストを開き、自分のIPアドレスを1行1つで登録

【スクショ⑦をここに（必須級）】
（Xserver「WordPressセキュリティ設定」画面。XML-RPCの項目とホワイトリスト編集が分かるところ）

10-3. 「自分のIPアドレス」ってどれ？

基本は「いま自分がインターネットに出ていく出口のIP」です。
検索で 「自分のIPアドレス 確認」 と打てば確認サイトが出ます。
注意点として、

  • IPv4とIPv6の両方が出る環境がある
  • ホワイトリストがどちらに対応しているかで、登録すべき値が変わる

…という点があります。迷ったら、まずは普段投稿するときの回線で確認し、そのIPを登録して動作確認するのが確実です。

10-4. 注意：IPが変わる環境だと、投稿できなくなる

  • 自宅回線でも、契約やルーター再起動でIPが変わることがあります
  • 外出先のWi-Fi、テザリング、VPNは特に変わりやすいです

つまり、ホワイトリスト運用は「その場所（回線）からの投稿に限定する」のと同義です。
逆に言えば、投稿環境が固定できる人ほど強い運用です。

私は「普段は自宅から投稿」「出先でどうしても必要なときだけ、その場のIPを一時的に追加→終わったら削除」みたいな運用にしています。

11. それでもブラウザ投稿を通したい人向け：記事の“壊し方”を減らす小ワザ

本当は「ブラウザからも普通に更新できる」が理想です。
ただ、現実にWAF誤検知が強い環境では、更新のたびに詰まります。そこで小ワザとして、本文の“危険語”を読者に伝わる形で分散させる方法があります。

  • 単語の途中にゼロ幅スペースを挟む（見た目は同じでもWAFが拾いにくい場合がある）
  • コマンドや危険語を画像にして添付し、本文は通常文中心にする
  • 「危険語の説明」パートだけ別記事にしてリンクする（運用で分散）

ただしこれは“最後の手段”です。記事としての読みやすさが落ちたり、検索性が下がることがあります。
今回の主役はあくまで、MarsEditで投稿経路を変えて、文章の自然さを守ることです。

12. トラブルシュート：MarsEditが投稿できないときのチェックリスト

  • XML-RPCを制限しすぎていないか（ホワイトリストにIPが入っているか／IPが変わっていないか）
  • WordfenceがXML-RPC自体をブロックしていないか（設定・ログを確認）
  • 専用ユーザーの権限が足りるか（下書き/公開の可否）
  • Cloudflare等の外部サービスを経由している場合、出口IPが想定とズレることがある（IP制限と相性チェック）

MarsEditの設定画面

まとめ：コード系ブログは「執筆経路を2本」＋「XML-RPCは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/

コメント

タイトルとURLをコピーしました