wpX Speedで「501 対応していないメソッド（MOVE/COPYなど）を使用した」と出た場合は、最初に実際のHTTPメソッド、完全なパス、発生時刻、応答ヘッダーを記録します。MOVEやCOPYはWordPress標準の通常閲覧では使わないため、WebDAV対応ソフト、バックアップ・移行ツール、プラグインが送っている可能性があります。wpXにはURLやルールIDを指定するWAF例外画面はありません。WAFが疑わしい場合は管理パネルのカテゴリを一つだけ短時間変更し、最大1時間の反映を待って同じステージング試験を行い、直ちに元へ戻します。
501・403・500を混同しない
RFC 9110の501 Not Implementedは、サーバーがリクエストを処理するために必要な機能を認識していない、またはどのリソースでもその機能をサポートできないときの応答です。メソッドは理解しているが、そのリソースで許可しない場合は405が適切です。実装や前段装置の挙動によって表示文言が簡略化されるため、エラーページの見た目だけで発生層を断定しません。
403 Forbiddenはリクエストを理解したうえで拒否した状態で、認可、アクセス制限、WAF検知などが候補です。500 Internal Server Errorはサーバーが予期しない状態に遭遇した応答で、PHP例外、プラグイン、設定不整合などを調べます。501を403や500の一般的対処へ置き換えると、メソッド非対応という中心情報を失います。
まず変更せずに証拠を取る
- 利用者が押したボタン、使用ソフト名と版、WordPress・プラグインの版、ログイン中のアカウントを記録する。
- ブラウザー開発者ツールのNetwork、クライアントログ、またはプロキシログでRequest MethodがMOVEかCOPYか、Request URLとStatusを確認する。
- 秒までのJST時刻、対象ホスト、完全なパス、Destinationヘッダーの宛先、応答本文の先頭、応答ヘッダーを保存する。
- 同時刻のWordPressデバッグログ、PHPエラーログ、プラグインログ、アクセスログで同一パスを照合する。
- 通常のGET、WordPress管理画面、REST API、別の小さなファイル操作が正常かを確認し、サイト全体障害か機能限定かを分ける。
Destination、Cookie、Authorizationなどには認証情報や内部URLが含まれる場合があります。画面記録やサポート連絡では値を伏せ、メソッド名、パス、時刻、応答コードなど調査に必要な部分だけを共有します。パスに個人名や案件名がある場合も匿名化し、元データはアクセス制限された調査記録へ保存します。
再現は隔離したパスで行う
MOVEやCOPYはデータを変更するメソッドです。本番記事、アップロード原本、バックアップ保管先へ向けて再現してはいけません。専用のステージング領域に削除可能な小さな試験ファイルを作り、操作前後のファイル一覧とハッシュを保存し、Destinationも同じ試験領域内へ限定します。試験後に元へ戻せる権限とバックアップがあることを確認します。
WebDAVクライアントが送る要求を再現する場合は、クライアントの詳細ログを優先します。curl等で手作業するなら、承認済み環境で実際のメソッドと安全なパスへ置き換え、例として「curl.exe -i -X MOVE https://example.jp/staging/source.txt -H “Destination: https://example.jp/staging/destination.txt”」のように応答を保存します。example.jpや例示パスを本番値と誤認せず、無害な試験ファイルだけで実施します。
同じ時刻に、GETは200だがMOVEだけ501になるか、COPYも同じか、認証前後で変わるかを比較します。メソッド自体をWebサーバーが提供していないなら、WAFを変えても成功しません。その場合はツール側でサポートされたPOST、PUT、WordPress REST API、SFTP等の公式手段に切り替えるのが解決です。
wpXのWAF操作面を正しく使う
wpX管理パネルでは、「WordPress管理」→「インストール済みWordPress一覧」→対象WordPressの「設定」→「セキュリティ設定」→「WAF設定」の「設定する」と進みます。設定できる単位はXSS、SQL、ファイル、メール、コマンド、PHPのカテゴリです。CloudflareのようなルールID、URI、式を指定する例外はこの画面にはありません。
各カテゴリは検知する文字列や操作が異なります。たとえばファイルカテゴリはサーバー設定ファイル等を含むアクセス、コマンドカテゴリはkill、ftp、mail、ping、ls等を含むアクセス、PHPカテゴリは危険性の高い関数を含むアクセスを対象にします。MOVEやCOPYというメソッド名だけから、どのカテゴリが原因かは決められません。記録したパス、ヘッダー、本文とカテゴリ説明を照合します。
最小の一時カテゴリ試験
- 現在の六カテゴリのON/OFF状態を画面記録し、作業責任者、開始時刻、復旧予定時刻を決める。
- 再現する一件と最も関係が強いカテゴリを一つだけ選ぶ。根拠が無ければ変更せず、先にwpXサポートへ確認する。
- 選んだカテゴリだけをOFFにして確定し、wpX公式の案内どおり最大1時間程度の反映時間を見込む。
- 反映中に別カテゴリを変更せず、試験パスへ同じメソッド、同じDestination、同じ認証条件で一度だけ送る。
- 結果、時刻、ステータスを記録したら、成功・失敗にかかわらずカテゴリをONへ戻して確定する。
- 再び最大1時間程度を考慮し、試験要求が拒否または元の挙動へ戻り、通常サイトが正常なことを確認する。
カテゴリをOFFにしたまま運用することは解決ではありません。WAFはWebアプリケーションの脆弱性悪用を抑える予防策であり、無効時間中は該当検知が働きません。試験中はアクセス元と時間を限定し、監視を強めます。成功した場合も、ツールやプラグインを更新する、不要なMOVE/COPYを送らない構成へ変える、wpXが提供する転送方式へ置き換えるなど恒久策を優先します。
WAF以外に確認する場所
WebDAV機能が必要なアプリケーションでも、wpXのWebサーバーがそのメソッドを提供しているとは限りません。製品の必要要件にMOVE/COPY、LOCK、PROPFIND等が含まれるかをベンダー公式資料で確認し、wpXのサーバー仕様と照合します。プラグインがWordPress REST APIで実現できる処理を独自WebDAVへ置き換えているなら、設定変更や別製品が必要です。
直前の更新後から発生したなら、更新前後の版、変更したプラグイン、.htaccess、セキュリティ設定を比較します。ただし本番でいきなり旧版へ戻さず、データベースとwp-contentを同じ時点でバックアップし、ステージングで戻した場合に501が消えるか検証します。500が併発していればPHPログ、403が併発していれば認証・国外アクセス制限も別系統として扱います。
wpXサポートへ渡す情報
一カテゴリの試験で結果が変わらない、メソッド対応可否が不明、または本番でしか再現しない場合は、推測でWAFを長時間外さずwpXサポートへ連絡します。公式問い合わせページは、シンクラウドアカウントID・サーバーID、エラーメッセージ、詳細な発生時間、ソフトウェア名、実施した作業を記載するよう案内しています。
- 対象ドメインとサーバーID。パスは必要範囲だけ記載し、認証トークンやCookieは送らない。
- JSTの発生日時を秒まで、Request Method、Request Path、Destinationのホストとパス、応答コード。
- 正常なGETと失敗するMOVE/COPYの比較、再現回数、ステージングでも同じか。
- WordPress、問題のプラグイン、クライアントの製品名と正確なバージョン。
- WAF六カテゴリの元の状態、一時変更したカテゴリ、OFF確定時刻、再試験時刻、ONへ復元した時刻。
- 501本文、関連するアクセスログ・PHPログの抜粋。秘密値と個人情報を除去したもの。
復旧と完了判定
一時試験後は、変更したWAFカテゴリが元どおりONであることを管理パネルと再試験で確認します。試験用に移動・複製したファイルを一覧とハッシュで確認し、原本が元のパスにあり、不要なDestination側ファイルが残っていないことを確認します。通常のトップ、管理画面、投稿保存、画像アップロードも検査します。
完了は単に501が一度消えた状態ではありません。恒久的にMOVE/COPYを送らない対応へ切り替えた、またはwpXが対応可能と公式サポートから確認し安全な設定を確定したこと、WAFが復元されていること、通常機能に副作用がないこと、再発時に同じメソッド・パス・時刻を採取できることまでを条件にします。
公式情報・参考資料
以下は2026年7月17日時点で確認した公式一次資料です。画面名や仕様が変わる可能性があるため、実作業の直前にも対象ページを確認してください。
コメント