スクレイパーがサーバーから無視された日 — 3回連続500エラーで分かったXSERVERの作法

- 4月 18, 2026

Webスクレイピングを自動化していると、ある日突然サーバーから無視される瞬間がある。その原因の多くは「レート制限」だ。自作スクレイパーで実際にレートリミットを食らい、ついでに相手のサーバーが XSERVER の wpX プランだと特定できたので、その記録を残しておく。

事件: 3回連続500エラー → 46分スリープ

WordPress系のサイトから約3,600件の記事を収集していたスクレイパーが、ゴールまで残り18件というところでいきなり黙り込んだ。ログを見るとこうなっていた。

[3660/3678] https://example.com/xxxx/

  リトライ 1/3: 500 Server Error (14.1s待機)

  リトライ 2/3: 500 Server Error (26.8s待機)

  ⚠ 3回連続500エラー → レートリミット検知。46分スリープ...

14秒・26秒とバックオフしても同じエラーが返ってくる。サーバー側が「お前もうちょっと待て」と本気で怒っているサインだ。ここで焦って再実行すると、クールダウンが延長されたり、最悪 IP ごと BAN される可能性がある。

相手サーバーを30秒で判別する方法

こういうとき、まず相手の正体を把握する。ターミナルで以下を叩くだけでほぼ分かる。

curl -sI https://example.com/ | head -10

dig +short example.com

dig +short example.com NS

whois <IPアドレス>

返ってきたヘッダーと DNS 情報を読み解くと、以下のことが判明した。

- server: nginx → Web サーバーは nginx
- IP のネームサーバーが ns1.wpx.ne.jp → エックスサーバーの wpX プラン（WordPress 特化の共有サーバー）
- whois 結果は XSERVER Inc. 大阪オフィス所在
- link: <.../wp-json/> ヘッダー → CMS は WordPress
- cf-ray ヘッダーなし → Cloudflare は経由していない

ここまで判明すると、対処方針が見えてくる。Cloudflare がいないのは正直ラッキーで、もし挟まっていたら JS チャレンジを突破できずスクレイパーが初手から機能しなかった可能性が高い。

レート制限は一般的？サーバー種別ごとの差

「どこのサーバーもレート制限ってかかるものなの？」と思うかもしれないが、強さには明確な差がある。

ホスティング種別	制限の強さ	典型例
Cloudflare前面	最強・自動学習	大手Webサービス
AWS/GCP + WAF	強・設定依存	企業サイト
XSERVER等レンタル	中・共有IPで連帯責任	今回のケース
個人VPS素の状態	弱・自前実装が必要	趣味サイト

共有レンタルサーバーは、同じ IP に同居している他ユーザーのサイトに迷惑をかけないために、思ったよりも強めに同時接続やリクエスト頻度を絞っている。しきい値を超えた瞬間に nginx の limit_req_zone か WordPress 側のセキュリティプラグインが 500 や 503 を返し始める、というのが定番の挙動だ。

今回の幸運ポイント

- CDN 未導入 → 素の nginx が相手なので挙動が素直
- JS チャレンジ不在 → 普通の HTTP リクエストで通る
- クールダウン明けの再開が可能 → 一時的ブロックで済んでいる

「優しいスクレイパー」の設計

スクレイパーを書くとき、何も考えずに for ループを回すと相手にもこちらにも悪い。今回問題なく完走目前まで来られたのは、以下のような設計を仕込んでいたおかげだった。

指数バックオフ

500系エラーが返ったら、14秒 → 24秒 → 40秒のように待機時間を倍々で伸ばす。1発目のエラーで諦めず、3回までは粘る。

連続失敗で本気のクールダウン

3回連続で 500 が返ったら、これは偶然ではなく「本気のレートリミット」と判定して、40〜50分のスリープに入る。人間ならコーヒー1杯飲んでもう一度試す感覚。

ランダム揺らぎ

完全に固定秒数で待つと「またこの時間帯に来やがった」と再検知されやすい。乱数を±20%くらい混ぜておくと、サーバー側から見てパターン化されにくくなる。

1件ごとにDB保存

途中で Ctrl+C しても、ネットワークが切れても、取得済みの記事は次回スキップできるように SQLite に都度コミットする。「再実行で続きから」が効くか効かないかで作業の精神的コストが段違いだ。

まとめ: 急がば回れ

今回の教訓をまとめると、こうなる。

- レート制限は「相手のサーバーが健全に機能する仕組み」であって、敵ではない
- curl -I と whois で相手のインフラは数十秒で把握できる
- Cloudflare がいない素の nginx はむしろ親切。500 を素直に返してくれる
- スクレイパー側は指数バックオフ + 長めのクールダウン + 途中保存の3点セットで組めば、事故を大幅に減らせる

ゴール直前でスリープに入ったスクレイパーも、おそらく1時間以内には残り18件を片付けて完走する。急がずに待つのが結局は一番早い、というのはスクレイピングに限らず色々な場面で同じだなと思った。

この記事が参考になったら、応援いただけると励みになります。

☕ Buy me a coffee

著者: ふじのすけ
作成: Claude Opus 4.7
投稿日: 2026-04-18 18:09 JST

このブログを検索

時間リッチ札幌日記