Proxy für mehrere Requests wiederverwenden
Erfahre, wie du denselben Proxy-Ausgang über Folgeanfragen hinweg beibehältst, sodass JavaScript-Renders, API-Aufrufe und paginierte Abrufe alle von derselben IP stammen.
Warum einen Proxy wiederverwenden
Wenn du ein Ziel zum ersten Mal ansteuerst, wählt FourA einen funktionierenden Proxy für dich aus. Jede Response enthält die verwendete Proxy-ID. Übergib diese ID bei späteren Anfragen und:
- Folgeseiten nutzen denselben Ausgang, sodass Session-Cookies und Rate Limits für das Ziel kohärent bleiben.
- Ein länderspezifischer Abruf bleibt ohne neue Auswahl in deiner Allowlist.
- Der günstige
POST /api/single/Endpoint wiederholt Anfragen über einen Proxy, für dessen Entdeckung du bereits bezahlt hast, zu den Kosten von Single statt von Proxy.
Die Proxy-ID ist ein opaker Base36-String (in etwa wie A1B2C3). Niemals eine rohe IP.
Wo die ID in einer Response steht
| Endpoint | Feld | Wann es vorhanden ist |
|---|---|---|
POST /api/auto/ |
session.proxy |
Wenn returnSession auf true steht (Standard) |
POST /api/single/ |
proxy (Top-Level) |
Nur wenn die Anfrage ein proxy Feld enthielt |
POST /api/proxy/ |
proxy (Top-Level) |
Immer, bei Erfolg |
POST /api/browser/ |
proxy (Top-Level) |
Nur wenn die Anfrage ein proxy Feld enthielt |
Um einen neuen Ausgang zu erhalten, ohne ihn festzupinnen, beginne mit Auto oder Proxy. Beide entdecken einen funktionierenden Ausgang und geben dessen ID für dich zurück.
Muster 1: Auto entdeckt, Single wiederholt
Am besten, wenn du ein Ziel hast, das du noch nicht kennst. Auto durchläuft die Leiter einmal, dann verwendet Single die erfolgreiche Session für jede Folgeseite wieder.
import requests
API = "https://eu.api.foura.ai"
H = {"X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json"}
# Step 1: discover a working exit with Auto.
r = requests.post(f"{API}/api/auto/", headers=H, json={
"url": "https://example.com/product/42",
"validate": {"data": {"accept": ["Add to cart"]}}
}).json()
session = r["session"]
proxy = session["proxy"]
user_agent = session["userAgent"]
# Step 2: paginate with Single, reusing the same exit and User-Agent.
for sku in ("43", "44", "45"):
p = requests.post(f"{API}/api/single/", headers=H, json={
"method": "GET",
"url": f"https://example.com/product/{sku}",
"proxy": proxy,
"headers": [["User-Agent", user_agent]],
}).json()
print(sku, p["status"])
Der Auto-Call kostet das, was seine Ladder verbraucht. Jeder weitere Single-Call kostet 2 Credits (Single mit unblocker, der Standard).
Pattern 2: Proxy entdeckt, Browser rendert über denselben Exit
Verwende dies, wenn das Ziel ein bestimmtes Exit-Land sehen muss und der finale Inhalt JavaScript benötigt.
# Step 1: pick a country-scoped exit with Proxy.
curl -X POST https://eu.api.foura.ai/api/proxy/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"exitCountries": ["FR", "GB"],
"request": {"method": "GET", "url": "https://example.com/pricing"}
}'
# Response includes: "proxy": "A1B2C3", "exitCountry": "FR"
# Step 2: render the JS-heavy page through THAT exit.
curl -X POST https://eu.api.foura.ai/api/browser/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/pricing",
"proxy": "A1B2C3",
"timeout_ms": 20000
}'
Rufe nicht /api/proxy/ erneut auf, um die Auswahl zu aktualisieren. Ein neuer Aufruf wählt möglicherweise einen anderen Exit und macht das Pinning zunichte. Wenn der gepinnte Exit nicht mehr funktioniert, führe einen neuen /api/proxy/ Aufruf aus, um einen neuen auszuwählen, und fahre damit fort.
Muster 3: Einen verbrannten Exit überspringen
Wenn ein Exit, der zuvor funktioniert hat, anfängt, Blockierungen oder CAPTCHAs zurückzugeben, weise FourA an, ihn bei der nächsten Auswahl zu vermeiden.
{
"maxTries": 5,
"ignoreProxies": ["A1B2C3"],
"request": { "method": "GET", "url": "https://example.com/data" }
}
ignoreProxies akzeptiert eine Liste von Proxy-IDs aus früheren Responses. Es funktioniert für /api/proxy/ und /api/auto/. Die Liste wird bei jedem internen Retry beachtet, sodass ein einzelner Aufruf mit ignoreProxies niemals die blockierten Exits wählt.
Wie lange eine gepinnte Session aktiv bleibt
Der Exit selbst lebt so lange, wie der zugrunde liegende Proxy fehlerfrei ist, typischerweise Minuten bis Stunden. Wenn ein Replay beginnt, Challenges, Blockaden oder unerwartete Redirects zurückzugeben, wurde der Exit wahrscheinlich rotiert oder das Ziel hat seine Freigabe aktualisiert.
Zwei Optionen, wenn das passiert:
- Neuer
/api/auto/Aufruf für dieselbe URL. Auto wird eine neue funktionierende Session entdecken; verwirf die vorherigen IDs. - Neuer
/api/proxy/Aufruf mitignoreProxies: ["<burned-id>"], wenn du weiterhin manuell pinnen möchtest.
Session Cookies aus einer Auto Response laufen ebenfalls nach dem eigenen Zeitplan des Ziels ab. Manche Seiten binden die Freigabe für Stunden, andere für Minuten. Behandle die Session als einen Cache, nicht als ein dauerhaftes Token.
Häufige Fehler
- Wiederverwendung einer Proxy-ID über Accounts hinweg. Proxy-IDs sind pro-Response-Identifikatoren. Die Weitergabe einer ID von einem API Key zu einem anderen garantiert nicht denselben Exit.
- Versuch, die ID zu dekodieren. Der base36-String ist undurchsichtig. Parse ihn nicht, entferne keine Zeichen, wandle ihn nicht in Kleinbuchstaben um. Gib ihn unverändert zurück.
- Pinnen über ein rate limit Exit. Wenn das Ziel ein rate limit pro IP hat, führt das Leiten vieler Requests über einen Exit schneller zu Blockaden. Lass Auto oder Proxy bei Workloads mit hohem Volumen über viele Exits rotieren und pinne nur dort, wo das Ziel es wirklich erfordert.
- Ignorieren von
exitCountriesbeim Follow-up. Wenn du einen gescopten Exit pinnst und dann Proxy erneut ohneexitCountriesaufrufst, kann der Follow-up über ein anderes Land erfolgen. Behalte den Scope bei jedem Aufruf, der ihn benötigt.
Verwandt
- API Endpoints: Vollständige Parameter- und Response-Referenz
- Smart Fetch (Auto): Wie Auto die Session aufbaut, die du wiederholst
- Umgang mit Anti-Bot-Schutz: Wann Pinnen hilft und wann Rotation besser ist
- Häufige Probleme:
no_eligible_proxyund andere Proxy-Fehler