※本記事にはプロモーション（広告）が含まれています。
ブラウザを開いたら「403 Forbidden」という画面が出て、でも家族のスマホで開くとふつうに表示される。こういう状況、かなりドキッとしますよね。
サイトが壊れたわけでも、消えたわけでもありません。「あなたのアクセスだけがサーバーに弾かれている」という状態です。理由がわかると、たいてい短時間で戻せます。
XserverやConoHa WINGを使っているなら、この記事が参考になります。
「403 Forbidden」って何が起きてるの？
まずひとことで言うと、403というのは「アクセスは届いているけれど、サーバーが拒否した」という意味のエラーです。
イメージしやすいのは「部屋のドア」のたとえです。
404が「そもそも部屋がない」なら、403は「部屋はあるけどドアを開けてもらえない」という状態です。サーバーはリクエストを受け取っているのに、何らかの理由で「あなたには見せられない」と判断して弾いているわけです。
インターネットの通信では、「見たいページにアクセスする → サーバーが応じる」という流れになっています。サーバーが「どうぞ」と返すのが200（正常）。「見つかりません」と返すのが404。「あなたには見せられない」と返すのが403です。
サイト全体がダウンしているなら他の人も同じ画面を見るはずです。自分だけ403が出るということは、あなたのブラウザやIPアドレスが何らかの理由で弾かれているか、あなたがアクセスしようとしたページやファイルだけに問題があるかのどちらかです。
原因は2つある。あなたの環境側か、サーバー側か。
ひとつは「あなたの環境側の問題」です。IPアドレスがブロックされている、Cookie（クッキー）やキャッシュ（過去のデータ）が悪さをしている、VPN（仮想プライベートネットワーク）を使っていて海外のIPアドレスと判定されている、ブラウザの拡張機能が干渉しているなど。
もうひとつは「サーバー側の設定の問題」です。WAF（ウェブアプリケーションファイアウォール、つまりサーバー側の不正アクセス防御機能）があなたのアクセスをブロックした、.htaccessというサーバーの設定ファイルに誤りがある、ファイルやフォルダのパーミッション（アクセス権限）が間違っているなど。
どちらが原因かによって操作が変わります。まず「あなたの環境側」から試すのが一番早い。
自分だけ403が出るのはなぜ？
IPアドレスが一時的にブロックされた
WordPressの管理画面にログインしようとして、パスワードを何度も間違えた直後に403が出たなら、これが原因の可能性が高いです。
セキュリティプラグイン（SiteGuardやAll In One WP Securityなど）が「不審なアクセス」と判断して、あなたのIPアドレスを一時的にブロックするのです。
同じWi-Fiを使っている家族の端末は影響を受けませんが、あなたの端末からのアクセスだけが弾かれます。この場合、しばらく（30分〜数時間）時間を置けば自動的に解除されることが多いです。
急いでいるなら、スマホのWi-Fiをオフにしてモバイルデータ通信（キャリアのネット回線）に切り替えてアクセスしてみてください。IPアドレスが変わるので、ブロックを回避できます。
Cookie（クッキー）やキャッシュが古くなった
ブラウザはアクセスを速くするために、過去に訪れたページのデータを手元に溜め込んでいます。これがキャッシュです。また、ログイン情報などを記憶しておくCookieというデータも持っています。
サイトの設定やサーバーの状態が変わったとき、この古いデータと現在の状態が食い違って403が出ることがあります。他の端末では問題ないのに自分だけ403になるときの、意外と多い原因です。
まず試してほしいのはブラウザのキャッシュとCookieの削除です。
VPN（仮想プライベートネットワーク）を使っている
VPNとは、インターネットの接続を経由させるサービスで、使うとアクセス元のIPアドレスが変わります。セキュリティ目的や海外のコンテンツを見るために使う方もいます。
VPNをオンにしていると、あなたのアクセスが「海外のIPアドレスからのアクセス」として認識されることがあります。サーバー側のWAFが海外IPをブロックするように設定されていると、自分だけ403になります。
VPNを使っているなら一度オフにしてアクセスしてみてください。
ブラウザの拡張機能が干渉している
広告ブロッカー（uBlock Originなど）やセキュリティ系の拡張機能が、サーバーとのやり取りを変えてしまい、403のように見える状態を作ることがあります。
シークレットモード（プライベートブラウジング）で開いてみてください。シークレットモードでは多くの拡張機能が無効になります。シークレットモードで開けるなら、どれかの拡張機能が原因です。
ChromeならCtrl+Shift+N（Macはcommand+Shift+N）でシークレットモードを開けます。
まずこれだけやってみて
ブラウザのキャッシュとCookieを削除する
キャッシュとCookieの削除は、自分だけ403が出るときに最初に試すべき操作です。
Chromeの場合、画面右上の点々のアイコン（メニュー）→「設定」→「プライバシーとセキュリティ」→「閲覧履歴データの削除」を選びます。「Cookieと他のサイトデータ」と「キャッシュされた画像とファイル」にチェックを入れて削除します。
削除する期間は「全期間」を選ぶと確実です。
Safariの場合は「設定」→「Safariをリセット」または「詳細」→「Webサイトのデータ」から削除できます。
スマホ（iPhone）のChromeなら、アプリ右下の点々→「閲覧データを消去」→「Cookieとサイトデータ」「キャッシュされた画像とファイル」にチェックして削除します。
Androidの場合は、Chromeアプリの右上の点々メニュー→「履歴」→「閲覧履歴データを削除」から同様に操作できます。
別の端末・別のネットワークで試す
スマホのWi-Fiをオフにしてモバイルデータでアクセスしてみてください。
見えるなら、あなたのIPアドレスがブロックされているか、Wi-Fiルーター経由のアクセスに問題がある可能性があります。
別の端末（家族のスマホや職場のPCなど）でも同じく403が出るなら、あなたの環境ではなくサーバー側に問題があります。
ブラウザを変えて試す
Chrome、Safari、Firefoxなど別のブラウザで試すだけで解決することがあります。特定のブラウザのキャッシュや設定が原因のときに有効です。
これらを試しても403が続くなら、サーバー側の設定を見ていきます。
サーバー側が怪しいときは
ここからはサーバー側の設定を確認する操作になります。WordPressの管理画面にログインできている前提で進めます。
WAF（サーバー側の不正アクセス防御機能）がブロックしている
WAFとは「Web Application Firewall（ウェブアプリケーションファイアウォール）」の略で、悪意のあるアクセスや攻撃を自動でブロックするサーバー側の防御機能です。
レンタルサーバーのほとんどがWAFを標準で提供しています。ただ、このWAFが「正常なアクセスなのに不審と判断する」誤検知を起こすことがあります。特にWordPressの管理画面操作中（プラグインのインストール、投稿の公開など）に403が出る場合は、WAFが原因のことが多いです。
WordPressの管理画面から操作したとき限定で403が出るなら、WAFを疑います。
Xserver（エックスサーバー）の場合：
サーバーパネルにログインします（WordPressの管理画面とは別の画面です）。サーバーパネルのURLはXserverから届いた契約完了メールに記載されています。ログイン後、「セキュリティ」→「WAF設定」を開くと、ドメインごとにWAFのオン/オフを切り替えられます。
一時的にオフにしてアクセスを確認してください。操作できるようになったらオンに戻します。ずっとオフにするのはセキュリティ上おすすめしません。
必要なら「除外設定」でWordPressの管理画面URL（/wp-admin/）をWAFの対象外にすることもできます。投稿操作中にだけ403が出る場合は、この除外設定の方が恒久対応として適しています。
ConoHa WING の場合：
管理コンソール（wing.conoha.jp）にログインして、「サイト管理」→「セキュリティ」→「WordPressセキュリティ」を開きます。「WAF設定」の項目でオン/オフを切り替えられます。
ConoHa WINGは「WAF自動有効」がデフォルト設定になっています。WordPressの管理画面操作で突然403が出た場合はここを確認してみてください。
WAFをオフにして問題が解決したら、そのまま一般の操作を終えてからオンに戻す、が基本の対処です。
.htaccess（サーバーの設定ファイル）に問題がある
.htaccessとは、サーバーの動作をフォルダ単位で細かく制御できる設定ファイルです。WordPressが自動で書き込むほか、プラグインが変更を加えることもあります。
この.htaccessに誤った記述が入ると、正常なアクセスを拒否してしまいます。WordPress本体やプラグインの更新後に403が出るようになったなら、.htaccessが書き換わった可能性があります。
対処するにはFTP（サーバーにファイルを送受信するソフト）かサーバーのファイルマネージャーで、WordPressのルートフォルダ（＝WordPressを設置した一番上のフォルダ）にある.htaccessを開き、内容を確認します。
操作前に必ずバックアップを取ってください（.htaccess_bakのようなファイル名でコピーしておくと安心です）。
WordPressの標準的な.htaccessの内容はこれだけです。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
これ以外の行が増えていたり、文字化けが起きていたりしていれば、何かのプラグインや更新が書き換えた可能性があります。
バックアップを取ってから、内容を上記の標準形に書き換えてアクセスを確認してみてください。.htaccessの変更は即時反映されます。ただし間違えるとWordPress全体が動かなくなるので、必ずバックアップを取ってから行ってください。
Xserverのファイルマネージャーから.htaccessを確認する手順：
サーバーパネルにログインし、「ファイル管理」→「ファイルマネージャー」を開きます。対象ドメインのフォルダ内「public_html」の直下に.htaccessがあります。ファイルが見えない場合は「隠しファイルを表示」をオンにしてください。
ConoHa WINGのファイルマネージャーから確認する手順：
管理コンソールから「サイト管理」→「ファイルマネージャー」を開きます。左のツリーから対象ドメインを選び、「public_html」直下の.htaccessを確認します。ConoHa WINGもデフォルトでは隠しファイルが非表示になっているので、表示設定を変えてから確認してください。
パーミッション（ファイルのアクセス権限）が間違っている
パーミッションとは、ファイルやフォルダに対して「誰が何をしていいか」を決めた数値設定です。FTPソフトで確認すると「755」「644」などの数字で表示されます。
この数値が間違っていると、サーバーがファイルを読み取れずに403を返すことがあります。
WordPressで推奨されるパーミッションの目安は以下の通りです。
| 対象 | 推奨値 |
|---|---|
| フォルダ（ディレクトリ） | 755 |
| ファイル | 644 |
| wp-config.php | 600（または400） |
FTPソフト（FileZillaなど）でWordPressのルートフォルダ（＝WordPressを設置した一番上のフォルダ）を確認し、数値がかけ離れている（777や400になっているなど）フォルダやファイルがあれば修正します。
777はセキュリティ上危険な設定（誰でも書き込める状態）なので、見つけたら755か644に変更してください。
サーバー乗り換えやプラグインの一括インストールなどの後にパーミッションが変わることがあります。
FileZillaでパーミッションを確認・変更する手順：
FTPソフト「FileZilla」を使っている場合は、変更したいファイルまたはフォルダを右クリックして「ファイル属性（パーミッション）」を選びます。数値欄に755や644を入力して「OK」で反映されます。複数のフォルダをまとめて変更したいときは、「再帰的に適用」にチェックを入れると配下のファイルにも一括で適用できます。
サーバー移行後・SSL設定後に急に403が出たとき
サーバーを別のサービスに移行した直後や、SSLを設定してURLがhttp://からhttps://に変わった直後に突然403が出るケースがあります。
サーバー移行後に403が出る
移行後は、WordPressの設定ファイル（wp-config.php）の情報（データベースへの接続情報など）が新しいサーバーの環境と食い違っていることがあります。また、.htaccessも旧サーバーの設定が残ったままになっていることがあります。
対処の順番はこうです。
まず.htaccessをWordPressの標準形に書き換えます（前のセクション参照）。それでも直らない場合は、wp-config.phpのDB_HOST（＝データベース接続先のサーバー名を書く項目）が新サーバーの値と一致しているか確認します。
DB_HOSTの値はサーバーによって違います。Xserverなら「mysql（番号）.xserver.jp」といった形式です。新サーバーのコントロールパネルやマニュアルで確認してから書き換えてください。
移行ツール（All-in-One WP Migrationなど）を使った場合は、ツールが.htaccessを書き換えていないかも確認ポイントです。
SSL設定後（https化後）に403が出る
http://からhttps://への変更後、WordPressの「設定」→「一般」にある「WordPressアドレス（URL）」と「サイトアドレス（URL）」が更新されていないと、リダイレクト（＝自動で別URLに転送する仕組み）がループして403のような症状が出ることがあります。
確認する場所は2つです。
ひとつはWordPressの管理画面の「設定」→「一般」。WordPressアドレスとサイトアドレスが両方https://で始まっているか確認します。http://のままになっていたら、https://に書き換えて「変更を保存」してください。
もうひとつは.htaccessのリダイレクト設定。https化にあたってサーバー側が自動で.htaccessにリダイレクトコードを追加しているはずです。このコードが二重になっていたり、WordPressの標準コードと順序が逆になっていたりすると問題が起きます。
Xserverの場合は「.htaccess編集」画面（サーバーパネル内）でhttp→httpsのリダイレクト記述とWordPressの標準記述が重複していないか確認してください。
ConoHa WINGは独自の管理コンソールからSSL設定を完結できますが、手動で.htaccessも編集していた場合は重複に注意です。
リダイレクトが二重になっているときの直し方：
.htaccessを開いたとき、以下のようなhttps転送の記述がWordPressの標準コードの外側と内側に両方あると、ループが起きてしまいます。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
...
</IfModule>
上記のような形なら問題ありません。「# BEGIN WordPress」の中にもhttps転送の記述が入り込んでいたら、そちらを削除して保存してください。
一部のページだけ403になるとき
特定のURLにアクセスしたときだけ403が出て、他のページは問題ない場合は、そのページやディレクトリだけに設定の問題があります。
特定のディレクトリにアクセス禁止が設定されている
WordPressのwp-content/uploads/やwp-admin/など、特定のフォルダに対してアクセス制限が設定されていることがあります。
セキュリティプラグインが自動でこういった制限を加える場合があります。たとえばAll In One WP Securityを使っていると、uploads/フォルダ内のPHPファイルへのアクセスが自動でブロックされます。これ自体は正しい動作ですが、何かの理由で範囲が広がりすぎたときに問題になります。
該当フォルダに.htaccessファイルが独自に作られていないか確認してみてください。
uploads/フォルダに入っている.htaccessの例：
All In One WP Securityなどが自動生成する場合、uploads/フォルダの中に以下のような.htaccessが作られていることがあります。
<Files "*.php">
deny from all
</Files>
これはPHPファイルへのアクセスを拒否する正常な設定です。ただし、何らかの操作でこの記述が拡張されたり、画像ファイルへのアクセスまで制限するコードが混入したりすると、画像が表示されなかったり403になったりします。不審な記述が追加されていたら削除してください。
特定のプラグインが原因
プラグインを有効化した直後から特定のページで403が出るようになった場合は、そのプラグインが.htaccessを書き換えた可能性があります。
確認方法は、問題が始まった直前に有効化したプラグインをFTPから無効化することです。FTPで操作する場合は、WordPressのwp-content/plugins/フォルダ内の対象プラグインフォルダの名前を変えます（例：siteground-optimizer → siteground-optimizer_BAK）。フォルダ名が変わるとWordPressはそのプラグインを認識できなくなり、無効化と同じ状態になります。
管理画面にはいれる状態なら、「プラグイン」→「インストール済みプラグイン」から無効化できます。
疑わしいプラグインを無効化して403が解消するなら、そのプラグインの設定を見直すか、別の同系統のプラグインへの変更を検討します。
ファイルそのものが存在しないURL
アクセスしようとしているURLのファイルが実際には存在していないとき、サーバーの設定によっては404ではなく403が返ることがあります。
URLのスラッシュの有無（/page vs /page/）や大文字小文字の違いで別のURLとして処理されることがあります。URLを見直してみてください。
WAFの誤検知でWordPress操作中だけ403が出るとき
管理画面にはログインできているのに、記事を投稿しようとしたり、プラグインの設定を変えようとしたりした瞬間に403が出る場合があります。
これは高い確率でWAFの誤検知です。
投稿内容や設定変更の内容が「攻撃コードっぽい」とWAFに判断されると、操作がブロックされて403になります。HTML編集でコードを書いているとき、問い合わせフォームの内容によっては誤検知が起きやすくなります。
このケースの対処は前述のWAF設定の確認（Xserver/ConoHaのサーバーパネルで一時オフ）が基本です。
投稿内容が原因であれば、その投稿の中に含まれている特定の文字列が誤検知を引き起こしているケースもあります。コードブロックにPHPやJavaScriptを貼り付けたときに起きやすいので、疑わしい部分を一時的に取り除いて試してみてください。
WAFの誤検知が起きやすいコンテンツの例：
特にWordPressの投稿編集中にWAFがブロックするのは、次のような内容が多いです。
- HTMLタグを直接書いたとき（scriptタグ・iframeタグ）
- PHPのコードをコードブロックで貼り付けたとき
- SQLクエリのような文字列（SELECTやDROP TABLEなど）を含む投稿
- 問い合わせフォームで「<」「>」「’」「”」などの記号が大量に含まれた入力
これらは攻撃コードと見分けがつきにくいため、WAFが誤ってブロックします。特定のコードを記事に掲載したい場合は、WAFの除外設定にその操作のURLを追加するか、一時的にWAFをオフにして操作を済ませてからオンに戻すのが楽です。
何度も繰り返すなら、サーバー側を疑っていい
一度解決してもまた403が出てくるような場合、そのサーバー環境自体に問題が蓄積していることがあります。
WAFが繰り返し誤検知するなら設定の問題、プラグインが.htaccessを繰り返し書き換えるなら設定の競合が続いている状態です。どちらも「毎回対処する」ではなく、根本を直す必要があります。
また、共有サーバーの場合、同じサーバーを使っている別のサイトが攻撃を受けてサーバー全体のセキュリティが一時強化される、という状況もあります。自分のサイトに何も問題がなくても、しばらく403が続くことがあります。
こういった状況が続いていて、サーバー自体のパフォーマンスや安定性に不満を感じてきたなら、サーバーを変えることも選択肢になります。サーバー乗り換えを考え始めたなら、こちらの記事も参考にしてみてください。ConoHaのデータを守りながら移行する手順をまとめています。
ConoHa WINGを解約したらブログ・ドメイン・データはどうなる？次の移行先まで
結局どの順番で確認する？
403 Forbiddenが自分だけ出たとき、確認する順番をまとめます。
まずは「自分の環境側」から試します。キャッシュとCookieの削除、別の端末や別のネットワーク（モバイルデータ）でのアクセス確認、VPNをオフにする、シークレットモードで開く、ブラウザを変える。これだけで解決することが多いです。
それで直らなければ「サーバー側」を確認します。WAFの設定（Xserver/ConoHaの管理パネル）、.htaccessの内容、パーミッションの確認です。
サーバー移行後やSSL設定後に急に出たなら、WordPressの設定（サイトURL）と.htaccessのリダイレクト記述を確認します。
一部のページだけなら、そのページに関係するプラグインか、ディレクトリごとの.htaccessが問題の可能性があります。
よくある質問
403 ForbiddenはWordPressのエラー？それともサーバーのエラー？
403はサーバーが返すエラーです。WordPressの管理画面に入れない状態でも起きることがある、という点でWordPressのエラー（500エラーや白画面）とは性格が違います。
自分のブラウザやIPアドレスが弾かれている場合と、サーバーの設定ファイルやWAFの誤検知が原因の場合があります。管理画面にはログインできているかどうかで、どちらが原因かの見当がつきます。
管理画面にも入れない → IPブロック・Cookie/キャッシュ・VPNを疑う
管理画面は入れるが特定操作で出る → WAFの誤検知を疑う
管理画面そのものが403 → .htaccess・パーミッションを疑う
403を何度も繰り返すなら何が疑われる？
一度解決してもまた出てくる場合、WAFが何らかのアクセスパターンを繰り返しブロックしているか、プラグインが.htaccessを繰り返し書き換えているケースが多いです。
WAFの設定を確認して誤検知の原因を特定すること、問題のプラグインを特定して代替のものに変えることが根本対処になります。
また、共有サーバーの場合、同じサーバーを使っている別のサイトが攻撃を受けてサーバー全体のセキュリティが一時強化される、という状況もあります。しばらく間を置いて試すと解消することもあります。
「403 Forbidden nginx」と出た場合は？
nginxはWebサーバーのソフトウェアの名前です（ApacheやLiteSpeedと並ぶ主要なもの）。多くのレンタルサーバーで使われています。
「403 Forbidden nginx」と表示されても、対処法は同じです。.htaccessかWAFかパーミッションを確認する手順で進めてください。
自分だけ403が出ていて、いつまで経っても直らない場合は？
ここまでの確認を試してもまだ直らない場合は、サーバー側のログを確認するか、サーバーのサポートに問い合わせるのが近道です。ただし、サーバーサポートは個別のWordPress設定の詳細まで対応してくれないことも多いです。
レンタルサーバーの設定が複雑になっていたり、同じサーバーで問題が繰り返し起きたりするなら、サーバー自体の変更を検討する時期かもしれません。
キャッシュを削除してもすぐ403が出るのはなぜ？
キャッシュ削除で一時的に解決しても、またすぐ403になる場合は、IPアドレスのブロックが継続しているか、WAFが繰り返しトリガーされている可能性があります。
セキュリティプラグイン（SiteGuardなど）がIPブロックの履歴を持っていることがあります。管理画面にアクセスできるなら、プラグインの設定からブロック履歴を確認して、自分のIPアドレスを解除してください。
管理画面に入れない場合は、モバイルデータなどIPアドレスを変えてログインし、プラグインの設定を確認してください。
WordPress管理画面のダッシュボードは見えるのにメディアライブラリだけ403になるのはなぜ？
この症状は、wp-content/uploads/フォルダのパーミッションかそのフォルダ内の.htaccessが問題のことがほとんどです。
FTPでwp-content/uploads/フォルダを開き、パーミッションが755になっているか確認してください。
また、セキュリティプラグインがuploads/フォルダ内に.htaccessを自動生成している場合、その内容が意図せず画像へのアクセスを制限していることがあります。uploads/フォルダ内の.htaccessを確認し、不審なコードが入っていたら削除して試してみてください。
.htaccessを変更したら余計にアクセスできなくなった場合は？
.htaccessの変更で余計に問題が起きた場合は、バックアップしておいたファイル（.htaccess_bak）を元の.htaccessに戻すのが最速です。バックアップを取っていなかった場合は、上記に書いたWordPressの標準形を.htaccessに書き込むことで、最低限の動作に戻すことができます。
それでもサイトが動かない場合は、FTPでサーバーに接続してWP管理画面にアクセスし、「設定」→「パーマリンク設定」を開いて「変更を保存」するだけで.htaccessが再生成されることがあります（Xserverなどのレンタルサーバーではこれだけで直ることが多いです）。
関連するトラブルについては、こちらの記事もご覧ください。
コメント