先に結論
403は『ページがない』ではなく、要求を理解したサーバーが処理を拒否した応答です。CDN・WAF・ロードバランサー・オリジンのどこが返したかを先に確定し、認証、IP・地域制限、ファイル権限を一つずつ確認します。
最初に403を返した主体を決める
- URL、操作、発生時刻、レスポンスヘッダー、エラー画面、request IDやRay IDを保存する。
- 全利用者か特定アカウント・IP・地域・パスだけかを確認する。
- CDN／WAFのイベントと、同時刻のオリジンアクセスログを突き合わせる。
- ログイン前後、GET／POST、静的ファイル／管理画面で差を確認する。
- 直前のWAFルール、IP許可、認証、移行、権限変更を一つずつ戻せる形で確認する。
結論：WAFに拒否イベントがあればルールと入力条件、オリジンに403記録があれば認証・Webサーバー・ファイル権限を優先します。記録がなければ一つ前のCDN／LBを確認します。
発生範囲から原因候補を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| 特定IP・地域だけ | WAF、IP・国別制限 | セキュリティイベント、allow/deny、VPN・社内出口 |
| ログイン後だけ | ロール・セッション・CSRF | 権限、Cookie、トークン、認可ログ |
| POST・アップロードだけ | WAF rule・容量・内容制限 | rule ID、Content-Type、サイズ、入力条件 |
| 静的ファイルだけ | 公開範囲・親ディレクトリ | document root、実行ユーザー、index設定 |
| 移行直後から全体 | 所有者・設定・CDN経路 | 権限差分、virtual host、WAF、origin hostname |
| 一時的に大量アクセス後 | rate limit | 429と制限ログを確認 |
成功した1件との差分を比較する
- 同じURLで成功した要求を一つ選ぶ。
- 送信元IP、地域、アカウント、HTTP method、User-Agent、ヘッダー、入力サイズを比較する。
- CDN／WAFのrule IDとaction、オリジンstatus、認可ログを時刻でつなぐ。
- 例外許可は対象パス・method・送信元・期間を狭くし、変更理由を残す。
- 修正後も想定外の公開範囲が広がっていないか、未認証・別ロールで確認する。
移行・WordPressでも権限を広げすぎない
移行後の403はファイル所有者、親ディレクトリ、Webサーバー設定、プラグイン型WAFなど複数候補があります。バックアップと設定差分を保存し、一般論の数値へ一括変更せず、契約先と公式手順が示す実行ユーザー・必要権限を確認します。
避ける操作
- 原因未確認でWAF、認証、IP制限を全停止する。
- ファイルやディレクトリを一括で777へ変更する。
- 管理画面やオリジンをインターネットへ直接公開して迂回する。
- 403を404や200へ置換し、アクセス制御の不具合を隠す。
- 本番の秘密情報や認証ヘッダーを外部の検証サイトへ貼る。
公式情報
WORDPRESS / 復旧後の判断
同じ運用を続けるかは、復旧後に分けて判断
障害中に移転を始めると、原因と移行差分が混ざります。まず復旧と証拠保存を優先し、その後に停止損失・復旧工数・移転費を同じ条件で比較します。
移転比較が近い売上・問い合わせへの影響があり、同種障害が反復。復元や保守の負担が大きく、30〜90日内に移転を判断したい。
まだ移転しない単発の設定・プラグイン原因で復旧済み。正常なバックアップと復元手順があり、停止損失も小さい。
先に確定する月間訪問、停止1時間の損失、現行費用、復旧工数、容量・帯域、移転期限をそろえる。
よくある質問
403と401の違いは何ですか？
401は通常、認証情報が不足または無効である状態です。403はサーバーが要求を理解したうえで拒否しています。ただしCDN、WAF、オリジンのどこが返したかをログとヘッダーで確定します。
ファイル権限を777にすれば直りますか？
推奨しません。過剰な権限は情報改ざんや漏えいのリスクを増やします。実行ユーザー、必要な読み書き範囲、親ディレクトリ、Webサーバー設定を確認し、最小権限へ直します。
Cloudflareの403はオリジン障害ですか？
Cloudflareのブランドがない403はオリジン由来の場合があり、ブランド付きならWAFやセキュリティ機能が候補です。Ray ID、イベントログ、同時刻のオリジンアクセスログを突き合わせます。