WordPressで画像だけ403エラー｜原因はWAFの誤検知やった

WordPressで画像をアップロードしようとしたら403エラー。記事の下書きは普通に保存できるのに、画像だけ「閲覧できません」で弾かれる。

先に結論を言うと、原因はサーバーのセキュリティ機能（WAF）の誤検知やった。悪いことは何もしてなくても403は出る。ConoHa WING なら、ConoHa のコントロールパネルにある WAF のログで自分の誤検知の行を見つけて「除外」を押す。俺の時はそれで通った。俺の場合、自分のブログのログに、俺自身が「攻撃者」として記録されとった。

手順は2026年10月に ConoHa WING の公式ヘルプ「WAFの設定をする」の原文と突き合わせて直した。前の版と違う所は、その場で断っとく。

ある日突然、画像だけアップロードできなくなった

6月の中頃。AIと一緒に、ブログの画像を自動でアップする仕組みを作ってた時の話。記事の下書きは問題なく保存できる。なのに画像を送った瞬間だけ「403 閲覧できません」。

当時の俺はWAFなんて言葉も知らん。せやから真っ先に疑ったのは自分の作った仕組みのバグ。AIと何回も見直して、書き方を変えて、また403。ここでだいぶ時間を溶かした。

今思えばヒントは最初から出とった。「記事は通るのに画像だけアカン」。同じサーバーに送ってるのに片方だけ弾かれるなら、通り道のどこかに中身を見て選別しとるやつがおる、ってことやから。

ちなみに俺のきっかけは自動化の仕組みやったけど、WAFが見とるのは送られてくる中身や。WordPress の管理画面から普通に画像をアップする時も、同じ形の誤検知は起きうると思う（俺はそっちでは踏んでへん）。見るべき場所はこの先に書く内容と同じ。

そもそも403エラーって何？

HTTP の決まり（RFC 9110）では、403 は「サーバーは要求を分かったうえで、応じるのを断っとる」という番号。ページが見つからん時の404とは別もんで、403は「言うてることは分かった、けど渡さん」。

つまり、こっちの書き方がおかしいんやなくて、サーバー側の門番の判断で止められとる可能性がある。

犯人はWAF。自分のブログに「攻撃者」として記録されとった

WAF は Web Application Firewall の略で、サイトの弱いところを突く攻撃を見張って、止めてくれる門番。ConoHa WING にも入っとって、普段は完全に空気で、存在すら意識せんかった。

前の版では「最初からONになってる」と書いたけど、公式のヘルプには「「利用設定」を「ON」にすることで有効となります。」とあるだけで、最初からONかどうかは書いてなかった。俺はWAFという言葉も知らんうちに、もう効いとった。自分のが今どうなっとるかは、下の手順の5（WAF のタブ）を開いた所の「利用設定」で見られる。

どうやって気づいたか

AIと調べてるうちに、ConoHaのコントロールパネルにWAFのログがあると分かって開いてみた。そしたら「SQLインジェクション」っていう攻撃の検知記録がずらーっと並んどる。え、うちのブログ攻撃されてるん？と一瞬ビビった。

よう見たら、攻撃元のIPアドレスが全部自分。攻撃対象は画像アップロードの送り先。つまり、俺が画像を送るたびに、WAFが画像ファイルの中身を攻撃コードと見間違えて、送った画像が次々弾かれとった。

画像の何が引っかかっとったのか

前の版では「たまたま攻撃コードっぽい並びに見えることがあるらしい」と、人から聞いた話みたいに書いてた。8月に、自動で画像を上げる仕組みが別の画像1枚でまた403を踏んだ。その時は AI に引っかかる場所を詰めさせた。

• 名前を変えて同じ中身を送る → 403。ファイル名は関係ない
• 画像の頭から1,024バイトだけ送る → 通る。8,192バイトまで送る → 403
• 間を半分ずつ詰めていく → 3,992〜4,048バイト目のあたりに引き金があった
• 4分あけて同じ物を送り直す → また403。待っても変わらん

その辺りは画像の圧縮済みのデータで、読める文字は何も入ってへん。画像に悪い意図があるわけやなくて、圧縮した結果のバイトの並びが、たまたまWAFの見張っとる形に当たっとる、というのが AI の見立てで、俺もそう見とる。6月はログに「SQLインジェクション」と出とったけど、8月はログを開いてへんので、どの種類に当たったかは分からん。

WAFのログから「除外」して通す

ConoHa WING での操作は、公式のヘルプやとこう。

1. コントロールパネルにログイン
2. 上のメニューの「WING」
3. 左のメニューの「サイト管理」
4. 左のメニューの「サイトセキュリティ」
5. 上のタブの「WAF」
6. 「表示切替」で「ログ」を選ぶ
7. ログから、除外設定したい攻撃内容の「除外」を押す
8. 確認画面で「はい」

6月にAIと除外した時は、1回押したら同じ行が全部「除外解除」の表示に変わった。押した直後に画像アップを試したら一発で通った。まる2日引きずった403が、ボタン1個で終了。

公式の説明では、除外すると「除外設定をした攻撃内容のアクセスが遮断されなくなります」。IPごとに分けるとは書いてない。俺は「その攻撃内容は、誰から来ても止めんようになる」と見とる。つまり外した攻撃内容は、本物の攻撃として来ても止まらんようになる。これが除外の代償で、8月にまた403を踏んだ時に除外を増やさんかったのもこのためや（後で書く）。

押す前に1個だけ確認してほしいこと

除外していいのは「攻撃元が自分のIP」で、しかも攻撃対象が自分の画像のアップロードの送り先になっとる行だけ。時刻が出とれば、自分が画像を上げた時刻と合うかも見る。IP を確かめるのは、その行が誤検知か本物の攻撃かを見分けるため。知らんIPからのXSSやらOSコマンドやらの検知は、本物の攻撃の可能性があるから絶対に除外したらアカン。自分のIPは「確認くん」みたいな確認サイトですぐ調べられる。

除外したあとに知っときたいこと

• WAF自体はONのまま。切る必要はないし、切ったら WAF の守りが消える
• 今なにを除外しとるかは、「表示切替」で「除外中」を選ぶと見られる。前の版では「除外中」から元に戻せると書いたけど、公式の説明やと、解除は「ログ」の画面の「除外解除」から
• 前の版にあった「接続IPが変わると同じ誤検知が再発することがある」は消した。確かめた記録が無かったし、公式の説明には IP で分けるとは書いてない
• 除外しても、別の画像が別のところで引っかかることはある。8月のは、記録では6月と同じ SiteGuard Lite（ConoHa WING の WAF の中身）の403として残っとるので、同じ WAF に止められたと見とる。どの決まりに当たったかは、ログを開いてへんので分からん。その時は AI が出した案のうち、除外を増やさず（増やすほど WAF を緩めることになるから）、画像を作り直して1回だけ上げ直す決まりを俺が選んだ。同じファイルを送り直すだけでは、上に書いたとおり4分あけても403のままやった。AI で絵を作り直した物は圧縮の結果も変わるので、通る見込みが高いと見とる

同じ症状で困ってる人へ

403が出ると、自分が何か悪いことしたように見える。けど、俺の時は門番の誤検知やった。記事は保存できるのに画像だけ弾かれるなら、まずWAFのログを見るのが早い。

ConoHa以外のサーバーでも、サーバーのコントロールパネル（管理画面）のセキュリティの設定にWAFのログや除外の項目があれば、同じ順で見られるはず。各社の画面や手順までは俺は確かめてへんので、「使ってるサーバー名 WAF 除外」で公式のヘルプを探すのが確実。

エラーの出方と本当の原因がズレとったWordPressの話は、URLだけ違っとったWordPressのスラッグに-2が付く原因と、置いただけでは動かんかったWordPressでLPを作る｜静的HTMLと違った4つのことにも書いた。

WordPress の不具合で困っとったら

画像が上がらん、保存した時だけエラーになる。そういう困りごとは、出とる画面とエラーを見せてもらえたら、原因の当たりと直し方をこちらで書き起こします。

相談する（メッセージのみ）