requests 403 Forbidden対処【26年8月】

「User-Agentを本物のブラウザに偽装したのにrequests 403 Forbiddenが消えない」という相談は受託案件でも頻出です。ヘッダー偽装は403対策の入り口に過ぎず、原因によっては全く効果がありません。本記事では403エラーの原因を4パターンに切り分け、それぞれの具体的な診断手順と実装での対処法を解説します。

403 Forbiddenの原因は4パターンヘッダー偽装で直らない理由

403は「サーバーがリクエストを認識した上で拒否した」状態です。原因ごとに有効な対策がまったく異なるため、まず切り分けが必須です。

①IPアドレスベースのブロック・レート制限

同一IPからの短時間大量アクセスをWAF（Web Application Firewall）やCDNが検知し、そのIP自体を一定時間ブロックしているケース。ヘッダーをどれだけ偽装してもIPが変わらない限り解除されません。

②TLSフィンガープリント（JA3/JA4）による判定

近年増えている原因がこれです。TLSハンドシェイクの暗号スイート・拡張の並び順は、Pythonのrequests（内部はopenssl経由）と実際のChromeブラウザとで異なります。サーバー側はこの「指紋」からbotを判別するため、HTTPヘッダーのUser-Agentをどう偽装してもTLS層で見破られ403を返されることがあります。これがヘッダー偽装だけでは突破できない最大の理由です。

③Cookie・セッション未確立

トップページでセッションCookieを発行し、そのCookieを持たないリクエストを弾くサイトも多くあります。いきなり商品一覧ページなどにGETを投げると403になり、事前にトップページへアクセスしてCookieを取得してから本命ページへ遷移すると通ることがあります。

④Cloudflare等のJSチャレンジ・bot検知

Cloudflare・Akamai・PerimeterXなどは、ブラウザ上でJavaScriptを実行させてその結果を検証する仕組みを持ちます。requestsはJavaScriptを実行できないため、この種のチャレンジページ自体が403（またはチャレンジHTML）として返ってきます。

症状	疑われる原因	切り分け方法
最初は通るが連続アクセスで403	①IPブロック・レート制限	アクセス間隔を空けて再試行し復帰するか確認
1回目から常に403	②TLSフィンガープリント	curlの--tlsv1.2指定やcurl_cffiで再現テスト
トップは200・下層ページのみ403	③Cookie未確立	ブラウザのDevToolsでCookie付与タイミングを確認
レスポンスがHTMLで"Checking your browser"等	④JSチャレンジ	レスポンス本文にCloudflare関連の文字列がないか確認

原因切り分けの手順 curlとブラウザで比較する

推測で対策を打つと時間を浪費します。以下の手順で機械的に切り分けます。

ブラウザのDevTools（Network タブ）で対象URLに実際にアクセスし、正常時のリクエストヘッダー・Cookie・レスポンスコードを記録する
同じURLにcurl -vでアクセスし、ブラウザと同じヘッダーを付けても403になるか確認する
curlで通るのにrequestsで403になる場合はTLSフィンガープリントを疑う
時間を空けて再試行し、復帰するならレート制限・IPブロックを疑う

# ブラウザと同じヘッダーを付けてcurlで確認
curl -v -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
  -H "Accept-Language: ja,en-US;q=0.9" \
  -H "Accept: text/html,application/xhtml+xml" \
  "https://example.com/target-page"

# requestsで同条件を再現
python3 -c "
import requests
headers = {
    'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
    'Accept-Language': 'ja,en-US;q=0.9',
}
r = requests.get('https://example.com/target-page', headers=headers)
print(r.status_code, r.text[:200])
"

curlで200・requestsで403になった場合は、②のTLSフィンガープリントが原因である可能性が高いと判断できます。

対処法を原因別に実装する

①IPブロック・レート制限への対処

アクセス間隔を空け、必要に応じてプロキシをローテーションします。まず自サイトへの負荷を減らす方向で解決できないか検討すべきです。

import time
import random
import requests

for url in url_list:
    r = requests.get(url, headers=headers)
    if r.status_code == 403:
        time.sleep(60)  # ブロック解除を待つ
        continue
    time.sleep(random.uniform(2, 5))  # 巡回間隔をランダム化

②TLSフィンガープリント対策

ブラウザと同じTLSハンドシェイクを再現できるcurl_cffiライブラリを使うと、標準のrequestsでは突破できないケースを解決できることがあります。

# pip install curl_cffi
from curl_cffi import requests as cffi_requests

r = cffi_requests.get(
    "https://example.com/target-page",
    impersonate="chrome124",  # Chromeのブラウザ指紋を再現
)
print(r.status_code)

③Cookie・セッション未確立への対処

requests.Session()でトップページに一度アクセスしてCookieを保持させてから対象ページへ遷移します。

session = requests.Session()
session.headers.update(headers)
session.get("https://example.com/")       # Cookie取得
r = session.get("https://example.com/target-page")  # 本命
print(r.status_code)

④JSチャレンジへの対処

ここまでで通らない場合、JavaScript実行が必須なbot検知が入っています。Playwrightなどのヘッドレスブラウザに切り替えるのが現実的な解決策です。動的サイトの操作テクニックはスクレイピング実践テク｜動的・ログイン攻略【26年8月】で詳しく解説しています。

規約・法令面で必ず確認すべきこと

403回避のテクニックは「技術的に可能」であることと「実施してよい」ことは別問題です。実装前に必ず以下を確認してください。

利用規約：スクレイピング・自動アクセスを明示的に禁止していないか確認する。403を意図的に回避する行為は規約違反の主張材料になりやすい
robots.txt：Disallowされているパスへのアクセスは避ける。法的拘束力は限定的だが、サイト運営者の意思表示として尊重すべき
不正アクセス禁止法：ID・パスワードでの認証を回避してアクセス制御を突破する行為は該当リスクがある。403回避は「アクセス制御の回避」に近づく行為であることを認識する
著作権法47条の5：取得したデータの利用目的（情報解析目的か再配布目的か）によって適法性が変わる
個人情報保護法：取得データに個人情報が含まれる場合は取得・保管・利用に別途の配慮が必要

特にログインが必要なサイトの認証回避や、明確に禁止されたAPI以外のエンドポイントへのアクセスは、技術的成否とは別に着手前にリスク評価を行うべきです。

この記事に関連するアイテム

実際に使うものを選ぶ際の参考にどうぞ。

Amazonで「スクレイピング」を探す

※ 本サイトはAmazonアソシエイト・プログラムの参加者です。紹介リンクを経由してご購入いただいた場合、手数料を受け取ることがあります。

自力対応の限界と外注判断の目安

403対策は「原因切り分け→実装→本番運用での再発監視」まで含めると継続的な工数がかかります。特に以下のようなケースは自力対応のコストが割に合わないことが多く、外注を検討する価値があります。

TLSフィンガープリント対策を入れても数週間で再ブロックされ、いたちごっこが続く
複数サイトを並行監視する必要があり、各サイトで原因パターンが異なる
取得対象がログイン必須かつ、規約リスクの判断も含めて相談したい

実装の総論はスクレイピング実装テクニック【2026年8月最新】も参考にしてください。

403 Forbiddenは「ヘッダー偽装で直る場合」と「TLSフィンガープリントやJSチャレンジなど根本的に別の対策が必要な場合」が混在しており、原因を切り分けずに対処すると時間だけが失われます。本記事の手順でまず原因を特定し、IPブロック・TLS・Cookie・JSチャレンジのいずれかに応じた実装を選んでください。あわせて利用規約・不正アクセス禁止法などの法令面のリスク評価も忘れずに行うことが重要です。

業務自動化・スクレイピングの導入をご検討の方はnashiまでお問い合わせください。https://nashi-portfolio.netlify.app

403 Forbiddenの原因は4パターン ヘッダー偽装で直らない理由