無料GitHub で公開日本語紹介

brightdata-common-errors

Bright Dataのプロキシやデータセットで起きたエラーを、HTTPステータスや最新のエラーコードから分類し、修正・再試行・停止・エスカレーションの判断を整理します。

原文原文の説明を見る

Analyze Bright Data proxy and dataset failures using current provider codes without bypassing policy controls. Use when diagnosing 407, 403, 429, 502, snapshot, or delivery failures. Trigger with: "diagnose a Bright Data error", "what does this x-brd code mean", "triage a failed snapshot".

jeremylongshore/tons-of-skills-marketplaceスター 2,884(GitHub 2,884 + cccskills 0)

実行スコア未検証

インストール方法を見る

こんなときに便利

Bright Dataの407や403を調べたいとき
429や502の原因を切り分けたいとき
失敗したスナップショットを調査したいとき
再試行かエスカレーションか判断したいとき

日本語での紹介

できること

Bright Dataのプロキシやデータセットで起きた失敗を、HTTPステータス、Proxy-Status、x-brd-* のエラー情報から分類します。認証、ポリシーによる拒否、リクエスト過多、接続先や相手側の問題、プロバイダーの障害、スナップショットの処理段階に関する失敗を切り分け、修正・制限内での再試行・一時停止・担当者へのエスカレーションを判断します。調査結果には、失敗の層、該当するコード、判断の根拠となる伏せ字済みの情報をまとめます。

こんなときに便利

407、403、429、502が返ったときや、スナップショットの作成・配信が止まったときの原因整理に向いています。エラーの記録から、次に確認すべき情報や安全な対応を整理したい運用担当者にも役立ちます。

使い方の例

「このBright Dataのエラーを、伏せ字済みの応答情報から分類して」
「この x-brd コードの意味と、再試行すべきかを整理して」
「失敗したスナップショットの状況を切り分けて」

注意点

調査には伏せ字済みの応答またはスナップショットの記録が必要です。現行のBright Dataエラー情報を参照できること、またはオフラインのテスト用記録を使えることが前提です。接続先を変えたり、ネットワークや識別情報を切り替えたりして、ポリシー上の拒否を回避する手順は扱いません。

この紹介文は、公開されている SKILL.md をもとに AI（OpenAI Codex）が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル（2）

SKILL.md3.4 KB
references/official-docs.md684 B

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Bright Data Failure Triage

Overview

Separate provider, target, client, and policy failures using HTTP status, Proxy-Status, and current x-brd-* fields. Never treat an access or compliance denial as a cue to rotate products, regions, or identities.

Prerequisites

A redacted response or snapshot receipt
The zone, product, operation ID, and approved target class
Access to the current Bright Data error catalog and network-status page

Instructions

Step 1: Collect minimal evidence

Read the receipt and Grep for status, Proxy-Status, x-brd-err-code, x-brd-error, x-brd-err-msg, snapshot state, and request time. Exclude credentials, full URLs, and bodies.

Step 2: Identify the layer

Classify authentication (407/client), policy (403/policy), throttling (429), peer/target (408/502), provider incident, or dataset lifecycle failure.

Step 3: Reproduce safely

Use Bash(curl:*) only for one authorized provider test endpoint or a read-only status check. Do not reproduce against a sensitive target or change network type to defeat a denial.

Step 4: Choose the response

Fix deterministic client/auth errors; back off transient/provider errors within budget; pause policy, target-data, account, empty, or persistent errors for owner review.

Tool Discipline

Use Read and Grep to analyze redacted evidence. Use Bash(curl:*) only for a bounded provider-controlled test. This workflow never writes raw response data, prints credentials, or authorizes product or identity switching.

Output

Failure layer and documented provider code
Retry, repair, pause, or escalate decision
Redacted evidence bundle identifier and owner

Examples

For 429 with a per-IP code, reduce pressure and review distribution; do not automatically rotate to more identities. For a policy 403, stop. For a provider-wide incident, preserve the receipt and wait for recovery.

Error Handling

Failure	Meaning	Response
Only an HTTP status is available	Provider detail was discarded	Capture current redacted headers on the next approved attempt
Legacy header is the only parser path	`x-luminati-*` support is stale	Migrate to `Proxy-Status` and `x-brd-*`
Failure repeats after bounded retry	Classification or provider state is unresolved	Open support escalation with sanitized identifiers

Resources

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

同じリポジトリのスキル