Jak nastavit vlastní proxy v Scrapy (připraveno pro produkci)

Váš Scrapy spider na 100 testovacích stránkách běží skvěle, ale na 10 000 se začne rozpadat. Ve skutečnosti to není chyba scrapingu — je to síťový problém, který je jen převlečený za chybu scrapingu. Řešení, po kterém sáhne skoro každý, je proxy, a její přidání do request.meta zabere asi třicet sekund.

Jenže právě u té třicetisekundové opravy většina základních návodů končí. Ukážou vám meta={"proxy": "http://IP:PORT"}, možná třídu middleware, a tím to považují za hotové. Často ale vynechají, co se stane, když proxy v půlce crawlů chcípne, jak se přihlašovací údaje dostanou do historie GitHubu, nebo proč retry může znovu použít stejnou nefunkční proxy. Tohle jsou produkční problémy, které tento průvodce řeší: konfiguraci typu fail-closed, správu tajných údajů, záměrný výběr proxy při opakování požadavku, limity protokolů i měřitelné nákladové kompromisy.

Co je proxy middleware v Scrapy?

Proxy middleware je kus kódu, který sedí v downloader pipeline Scrapy a rozhoduje, z jaké IP adresy má požadavek vypadat, že přichází, ještě než odejde na síť. Scrapy má vestavěnou verzi, HttpProxyMiddleware, která čte klíč proxy z request.meta, přidá proxy autentizaci, pokud je potřeba, a předá požadavek download handleru, který skutečně otevře spojení. Vlastní proxy middleware tedy nenahrazuje transportní vrstvu — je to spíš výběr, který rozhodne, jakou proxy vložit, než se ujme vestavěný mechanismus. Tenhle rozdíl je důležitější, než by se mohlo zdát, a je zdrojem většiny hlášek typu „můj custom middleware nefunguje“.

Proč jsou proxy důležité pro produkční Scrapy projekty

Proxy mění síťovou trasu i zdrojovou IP adresu, jak ji vidí cílový web. To může pomoct při legitimním testování podle geografické polohy, rozložit schválený provoz požadavků a izolovat síťové chyby. Nedává to ale automaticky povolení, neobchází limity rychlosti ani nezaručuje přístup. To, jestli je proxy vůbec potřeba, závisí na cíli, jeho podmínkách, rychlosti požadavků a na tom, jak spolehlivý má úkol být.

Ne všechny proxy jsou stejné a špatná volba je sama o sobě typ produkčního incidentu:

Typ proxy	Spolehlivost	Rychlost	Riziko detekce	Typická cena
Veřejné free proxy	Velmi proměnlivá	Proměnlivá	Často vysoké	Bez poplatku, ale s výrazným bezpečnostním a provozním rizikem
Datacentrové proxy	Závisí na poskytovateli a cíli	Často rychlé	Závislé na cíli	Obvykle účtováno za GB nebo za IP
Rezidenční proxy	Závisí na poskytovateli a cíli	Proměnlivá	Závislé na cíli	Obvykle účtováno za GB
ISP proxy	Závisí na poskytovateli a cíli	Proměnlivá	Závislé na cíli	Specifické podle poskytovatele

Free proxy si zaslouží zvláštní zmínku, protože měřená rizika jsou výrazná. Studie Free Proxies Unmasked trvající 30 měsíců sledovala více než 640 000 adres od 11 poskytovatelů: 34,5 % bylo alespoň jednou aktivních a 16 923 manipulovalo s obsahem. Tato data jsou silným bezpečnostním varováním pro veřejné seznamy; nejsou to ale přenositelná selhání pro každý aktuální seznam, placený pool, cíl ani workload.

Proxy také samy o sobě neporazí moderní bot detection. Služby jako Cloudflare vyhodnocují požadavky podle desítek signálů — TLS fingerprintů, konzistence hlaviček, provádění JavaScriptu, behaviorálních vzorců — a IP adresa je jen jeden z mnoha vstupů. Čistá rezidenční proxy na požadavku s nesourodými hlavičkami a bez cookie jaru bude pořád působit podezřele. Než postavíte celou architekturu na tom, že „prostě budu rotovat IP“, držte očekávání při zemi.

Než začnete

• Obtížnost: Střední
• Potřebný čas: přibližně 30–45 minut pro celé produkční nastavení, asi 5 minut pro rychlý test
• Co budete potřebovat: Python 3.9+, nainstalovaný Scrapy (tento návod je testovaný proti Scrapy 2.17.0, vydanému v červenci 2026), funkční spider ze scrapy startproject a alespoň jeden proxy endpoint (na testování stačí bezplatná zkušební verze od libovolného poskytovatele datacentrových proxy)

Krok 1: Otestujte proxy pomocí parametru request meta

Nejrychlejší způsob, jak ověřit, že proxy funguje, je obejít celý middleware systém a prostě ji vyzkoušet.

Vestavěný HttpProxyMiddleware ve Scrapy čte klíč proxy přímo z request.meta a směruje přes něj požadavek. Žádná změna settings, žádná třída middleware — jen jeden keyword argument.

import scrapy

class ProxyTestSpider(scrapy.Spider):
    name = "proxy_test"
    start_urls = ["https://httpbin.org/ip"]

    def start_requests(self):
        for url in self.start_urls:
            yield scrapy.Request(
                url,
                meta={"proxy": "http://203.0.113.10:8080"},
                callback=self.parse,
            )

    def parse(self, response):
        self.logger.info(response.text)

Spusťte to přes scrapy runspider proxy_test.py. Pokud proxy funguje, httpbin.org/ip vrátí IP adresu proxy místo vaší vlastní — tím máte potvrzení. Pokud se odpověď zasekne a nakonec spadne na TCP connection timed out, je proxy mrtvá nebo nedostupná, což — spoiler — se děje častěji, než by si vendorové rádi přiznali.

Tenhle postup je fajn pro jednorázové spidery nebo rychlé testy. Rozpadne se ve chvíli, kdy máte víc než jeden spider, protože pak tu samou proxy string hodnotu hardcodujete do pěti různých souborů.

Krok 2: Vytvořte vlastní proxy middleware

Pro cokoli nad rámec jednoho spideru chcete mít proxy logiku centralizovanou na jednom místě. Vytvořte třídu ProxyMiddleware v souboru middlewares.py:

from scrapy.exceptions import NotConfigured

class ProxyMiddleware:
    def __init__(self, proxy_url):
        self.proxy_url = proxy_url

    @classmethod
    def from_crawler(cls, crawler):
        proxy_url = crawler.settings.get("PROXY_URL")
        if not proxy_url:
            raise NotConfigured("PROXY_URL je povinné; odmítám tichý fallback na přímé spojení")
        return cls(proxy_url=proxy_url)

    def process_request(self, request, spider):
        if "proxy" not in request.meta:
            request.meta["proxy"] = self.proxy_url

A zaregistrujte ji v settings.py:

import os

PROXY_URL = os.environ.get("PROXY_URL")

DOWNLOADER_MIDDLEWARES = {
    "myproject.middlewares.ProxyMiddleware": 350,
}

Všimněte si použití from_crawler místo prostého __init__. To je pattern, který Scrapy skutečně doporučuje pro čtení settings, a stejný hook využijeme znovu v kroku 4, když budeme řešit tajné údaje. Výhoda je jednoduchá: změníte jedno nastavení a novou proxy převezmou všechny spidery v projektu. Žádné prohledávání pěti souborů kvůli výměně mrtvé IP.

Krok 3: Pochopte pořadí middleware, aby vaše proxy tiše nevypínala sama sebe

Tady je část, kterou skoro každý jiný návod přejde stylem „prostě nastavte prioritu na 350, věřte mi“. Downloader middleware ve Scrapy běží v konkrétním, předvídatelném pořadí a pokud mu nerozumíte, vaše proxy nastavení bude vytvářet chyby, které vypadají úplně nesouvisející s proxy.

Requestové hooky (process_request) běží v vzestupném pořadí priority — nejmenší číslo první. Response hooky (process_response, process_exception) běží v sestupném pořadí — nejvyšší číslo první, a pak se řetězec vrací zpět dolů.

Tok requestu (vzestupně):
  Spider → [100] RobotsTxt → [300] HttpAuth → [350] VAŠE PROXY MIDDLEWARE
         → [500] UserAgent → [550] Retry → [700] Cookies → [750] HttpProxy
         → Downloader

Tok response (sestupně):
  Downloader → [750] HttpProxy → [700] Cookies → [550] Retry
             → [500] UserAgent → [350] VAŠE PROXY MIDDLEWARE → [300] HttpAuth
             → [100] RobotsTxt → Spider

Tady je aktuální výchozí tabulka priorit pro vestavěné middleware Scrapy (ověřeno proti 2.17.0):

Middleware	Výchozí priorita
RobotsTxtMiddleware	100
HttpAuthMiddleware	300
DownloadTimeoutMiddleware	350
DefaultHeadersMiddleware	400
UserAgentMiddleware	500
RetryMiddleware	550
RedirectMiddleware	600
CookiesMiddleware	700
HttpProxyMiddleware	750
DownloaderStats	850
HttpCacheMiddleware	900

Když RetryMiddleware naplánuje opakování, zkopíruje neúspěšný request — včetně jeho metadat — a tento nový request znovu vstoupí do downloader middleware řetězce. Číselný vztah selectoru k prioritě 550 nezaručuje rotaci. Rotace nastane jen tehdy, když selector při opakování rozpozná retry a záměrně přepíše zkopírované meta["proxy"]. Priorita 350 je vhodné místo pro selector, protože běží před vestavěnou transportní vrstvou na 750, ale sama o sobě není mechanismem rotace.

Časté chyby v pořadí middleware

• Nastavení vašeho middleware na stejnou prioritu jako HttpProxyMiddleware (750): Vzniká race condition, kdy pořadí zpracování requestu určuje Scrapy podle pořadí v dictu, ne vaše logika. Příznak: občasné, nevysvětlitelné chování proxy.
• Použití setdefault() nebo if "proxy" not in request.meta v rotujícím selectoru: zkopírovaný retry si nechá starou proxy. Příznak: každý retry zopakuje stejnou neúspěšnou trasu. Oprava: detekujte retry (například přes retry_times > 0) a hodnotu proxy, kterou vlastní selector, explicitně přepište.
• Úplné vypnutí HttpProxyMiddleware: Některé návody radí nastavit "scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware": None, protože „custom middleware to vyřeší“. Nevyřeší — vaše middleware je selector, ne transportní vrstva. Když vypnete vestavěnou vrstvu, proxy auth hlavičky se nikdy nepřidají a požadavky odejdou bez autentizace (nebo vůbec neodejdou).

Krok 4: Přestaňte hardcodovat přihlašovací údaje k proxy

Každý návod na Scrapy proxy, který se vysoko umisťuje ve vyhledávání, zapisuje http://username:password@proxy.example.com:8080 přímo do Python souboru. To je přihlašovací údaj, který navždy žije v historii Git repozitáře, objeví se v každém klonu, každém forku i v log dumpu, když někdo neopatrně použije print().

Ve skutečnosti existují tři úrovně, jak to dělat:

Metoda	Bezpečnost	Flexibilita	Nejlepší pro
Hardcode v spider/settings.py	Slabá — tajné údaje jsou v repu	Nízká	Jen rychlé lokální testování
Proměnná prostředí http_proxy (nativní pro Scrapy)	Lepší — mimo kód	Nízká (jedna proxy)	CI/CD pipeline, Docker
.env + python-dotenv + from_crawler	Nejlepší — mimo kód, pro každé prostředí zvlášť	Vysoká (více proxy, rotace)	Produkční scrapeři

Třetí možnost stojí za to postavit pořádně. Nainstalujte python-dotenv, vytvořte .env soubor a hned ho přidejte do .gitignore — myslím to vážně, udělejte to hned teď:

PROXY_USER=myuser
PROXY_PASSWORD=my$ecret!Pass
PROXY_HOST=proxy.example.com
PROXY_PORT=8080

Načtěte ho nahoře v settings.py:

from dotenv import load_dotenv
import os

load_dotenv()

PROXY_USER = os.getenv("PROXY_USER")
PROXY_PASSWORD = os.getenv("PROXY_PASSWORD")
PROXY_HOST = os.getenv("PROXY_HOST")
PROXY_PORT = os.getenv("PROXY_PORT")

Pak je bezpečně načtěte uvnitř middleware přes from_crawler — to je přesně ten pattern, který řeší zmatek, na který jsem narážel na fórech ve stylu „jak to mám nastavit před scrapy crawl, když se credentials mění při každém běhu?“:

import os
from urllib.parse import quote

class SecureProxyMiddleware:
    def __init__(self, user, password, host, port):
        self.user = quote(user, safe="")
        self.password = quote(password, safe="")
        self.host = host
        self.port = port

    @classmethod
    def from_crawler(cls, crawler):
        settings = crawler.settings
        return cls(
            user=settings.get("PROXY_USER"),
            password=settings.get("PROXY_PASSWORD"),
            host=settings.get("PROXY_HOST"),
            port=settings.get("PROXY_PORT"),
        )

    def process_request(self, request, spider):
        proxy_url = f"http://{self.user}:{self.password}@{self.host}:{self.port}"
        request.meta["proxy"] = proxy_url

Všimněte si volání urllib.parse.quote() kolem přihlašovacích údajů. Pokud vaše heslo obsahuje @, : nebo / (a generátory hesel je tam rády házejí), rozbije se parsování URL, pokud nebude nejdřív percent-encoded. Je to jednorázová oprava, která ušetří trapnou hodinu ladění chyb typu „invalid proxy URL“, které s neplatností proxy vůbec nesouvisí.

Držte credentials mimo logy a testujte percent-encoding na reprezentativních — ale falešných — hodnotách. HTTPS tunneling, SOCKS5 a ne-latinské znaky v credentials mají hranice závislé na handleru; nepředpokládejte, že jeden autentizační pattern funguje všude, aniž byste měli připnutý integrační test.

Krok 5: Přidejte rotaci proxy

Jedna proxy — i dobrá — která vyšle 5 000 požadavků na stejný web, bude nakonec označena jako podezřelá. Potřebujete pool.

Možnost A — postavte si to sami. Je to opravdu jednoduché:

import random

class RotatingProxyMiddleware:
    def __init__(self, proxy_pool):
        self.proxy_pool = proxy_pool

    @classmethod
    def from_crawler(cls, crawler):
        return cls(proxy_pool=crawler.settings.getlist("PROXY_POOL"))

    def process_request(self, request, spider):
        request.meta["proxy"] = random.choice(self.proxy_pool)

Tohle funguje pro základní použití, ale vůbec neřeší, které proxy jsou skutečně živé. Každý požadavek je prostě hod kostkou.

Možnost B — použijte scrapy-rotating-proxies. Tenhle balíček od třetí strany přidává detekci blokace a automatický backoff rovnou z krabice:

pip install scrapy-rotating-proxies

Tady řeknu upřímně jednu věc: nejnovější release na PyPI je verze 0.6.2 z roku 2019 a projekt je označený jako Alpha. Nemusí být nutně rozbitý na moderním Scrapy, ale „neaktivně udržovaný od roku 2019“ není totéž jako „otestovaný pro produkční provoz v roce 2026“. Připněte verzi, otestujte ji proti svým skutečným cílovým webům a nepředpokládejte, že umí autentizované proxy endpointy — většinou neumí.

Krok 6: Postavte middleware odolný proti chybám (detekce mrtvé proxy)

Tohle je část, kterou konkurenční návody úplně vynechávají, a zároveň rozdíl mezi demo ukázkou a něčím, co přežije šestihodinový crawl bez dozoru.

Scénář	Co ukazuje většina návodů	Co přidává tento middleware
Proxy vrátí 407	Neřeší se	Bere to jako selhání autentizace proxy
Cíl vrátí 403/429	Často se hází do jednoho pytle	Odděluje feedback o politice/rate limitu od zdraví proxy
Proxy timeoutuje	Neřeší se	Konfigurovatelný práh timeoutu, pokles health score
Všechny proxy jsou mrtvé	Neřeší se	Graceful fallback nebo pauza crawlů s logovaným warningem
Proxy se chová nestabilně	Neřeší se	Ochlazovací perioda před vrácením do poolu

import time
import random
from scrapy.exceptions import IgnoreRequest

class FaultTolerantProxyMiddleware:
    MAX_FAILURES = 3
    COOLDOWN_SECONDS = 300

    def __init__(self, proxy_pool):
        self.pool = {p: {"failures": 0, "banned_until": 0} for p in proxy_pool}

    @classmethod
    def from_crawler(cls, crawler):
        return cls(proxy_pool=crawler.settings.getlist("PROXY_POOL"))

    def _healthy_proxies(self):
        now = time.time()
        return [p for p, s in self.pool.items() if s["banned_until"] < now]

    def process_request(self, request, spider):
        healthy = self._healthy_proxies()
        if not healthy:
            spider.logger.warning("Všechny proxy jsou nezdravé — pozastavuji crawl")
            raise IgnoreRequest("K dispozici nejsou žádné zdravé proxy")
        request.meta["proxy"] = random.choice(healthy)

    def process_response(self, request, response, spider):
        proxy = request.meta.get("proxy")
        if proxy and response.status == 407:
            self._mark_failure(proxy)
        return response

    def process_exception(self, request, exception, spider):
        proxy = request.meta.get("proxy")
        if proxy:
            self._mark_failure(proxy)

    def _mark_failure(self, proxy):
        state = self.pool[proxy]
        state["failures"] += 1
        if state["failures"] >= self.MAX_FAILURES:
            state["banned_until"] = time.time() + self.COOLDOWN_SECONDS
            state["failures"] = 0

Pár poznámek z reálné implementace: neberte každou 403 jako důkaz, že proxy je mrtvá — RFC 9110 definuje 403 jako „server požadavek pochopil, ale odmítá ho“, což může stejně dobře znamenat, že podezřele vypadají vaše hlavičky nebo session, a proxy s tím nemusí mít nic společného. Naproti tomu 407 znamená, že konkrétně proxy odmítá autentizaci — to je mnohem silnější a přesnější signál. Házet tyto signály do jednoho koše je přesně ten způsob, jak zbytečně spalovat zdravé proxy.

V produkci mějte explicitně nastavené transient retry defaulty, aby recenzenti viděli politiku jasně:

RETRY_HTTP_CODES = [500, 502, 503, 504, 522, 524, 408, 429]
RETRY_TIMES = 2

To jsou defaulty Scrapy 2.17. Nepřidávejte plošně 403 ani 407: 403 je odmítnutí cílem s mnoha možnými příčinami, zatímco 407 je problém autentizace proxy, který obecné retry požadavku stejně nevyřeší. Pokud konkrétní smluvní podmínky cíle odůvodňují retry jiného statusu, zdokumentujte to a otestujte zvlášť.

Krok 7: Měřený přístup proxy až při retry

Některé autorizované cíle mohou vracet platný obsah přímo a proxy potřebují až po zdokumentované dočasné odpovědi. To může snížit objem dat přes proxy, ale neexistuje žádné obhajitelné univerzální procento úspory ani přenositelná míra úspěšnosti přímých požadavků. Než tenhle pattern převezmete, změřte si vlastní workload.

Použijte veřejný helper get_retry_request() ve Scrapy a eskalaci držte jen na statusy specifické pro cíl, které jste si výslovně klasifikovali. Tento příklad považuje 429 a 503 za signály vhodné k retry; záměrně vynechává 403 a 407.

from scrapy.downloadermiddlewares.retry import get_retry_request

class CostAwareEscalationMiddleware:
    def process_response(self, request, response, spider):
        if response.status not in {429, 503}:
            return response

        retry = get_retry_request(
            request,
            spider=spider,
            reason=f"proxy_escalation_{response.status}",
            max_retry_times=2,
        )
        if retry is None:
            return response

        current_tier = request.meta.get("proxy_tier", "direct")
        if current_tier == "direct":
            retry.meta["proxy"] = spider.settings["DATACENTER_PROXY"]
            retry.meta["proxy_tier"] = "datacenter"
        elif current_tier == "datacenter":
            retry.meta["proxy"] = spider.settings["RESIDENTIAL_PROXY"]
            retry.meta["proxy_tier"] = "residential"
        else:
            return response
        return retry

Sledujte míru platného obsahu u přímých požadavků, míru platného obsahu přes proxy, počet bajtů na úspěšný záznam, počet retry na úspěch a přidanou latenci. Direct-first návrh je přijatelný jen tehdy, když je přímý přístup autorizovaný a systém se fail-closed chová ve chvíli, kdy je proxy nutná. Úspora je naměřené snížení provozu přes proxy — ne odhadované procento.

Kdy se DIY správa proxy nevyplatí

Chci to říct rovnou a nehrát si na to, že celý zbytek článku byl zbytečný: všechno výše uvedené je reálné a užitečné inženýrství, a pro spoustu projektů — vysokovolumové crawly, vlastní pipeline, cokoli, kde potřebujete plnou kontrolu nad plánováním požadavků — je to správná volba.

Ale pokud je váš skutečný cíl „dostat strukturovaná data z této stránky“ a ne „provozovat proxy infrastrukturu“, může být vhodnější extrakční API. Aktuální dokumentace Thunderbit POST /extract přijímá URL stránky a volitelný JSON Schema; když schema chybí, služba ho může vygenerovat z obsahu stránky. Endpoint také nabízí režimy vykreslení none, basic a full spolu s timeoutem a čekáním po načtení. Extrakce pouze na základě promptu není součástí aktuálně podporovaného request surface, proto stavějte produkční integrace kolem zdokumentovaného schema kontraktu. Tím se rozhraní pro extrakci přesune za jeden request; neznamená to ale univerzální slib pro každý anti-bot nebo CAPTCHA cíl.

Faktor	DIY Scrapy + proxy	Exktrakce přes API (např. Thunderbit)
Náročnost nastavení	Vysoká — middleware, rotace, retry logika	Nízká — jedno API volání se schema
Chování sítě/renderingu	Sami nastavujete handlery, proxy, hlavičky a zpoždění	Řízeno přes zdokumentované volby API
Údržba	Vy spravujete selektory, zdraví poolu a změny cíle	Vy spravujete kvalitu schema, validaci a integrační chování
Cenový model	Poplatky za proxy + compute + inženýrský čas	Aktuální dokumentace uvádí 20 jednotek na stránku (ověřeno 2026-08-10)
Kontrola	Plná — vlastní pipeline, middleware chain	Omezená možnostmi API
Nejlepší pro	Komplexní crawl, vysoký objem, vlastní logiku	Cílená extrakce, prototypování, enrichment

Pokud většinou extrahujete strukturované stránky pro lead listy, produktová data nebo research, spusťte reprezentativní pilot přes Thunderbit Chrome Extension nebo API a porovnejte počet platných záznamů, latenci, jednotky a čas na údržbu. Pokud váš projekt potřebuje vlastní crawl graph a řízení pipeline, Scrapy je pořád silnější volba.

Další informace

• Co je web scraping
• AI web scraping
• Nejlepší AI web scrapeři

Tipy a časté chyby

• Tip: Než proxy nasadíte na ostrý cíl, otestujte ji proti httpbin.org/ip. Je to nejrychlejší způsob, jak ověřit, že směrování funguje, ještě než na to navážete další vrstvy složitosti.
• Chyba: Nastavení proxy v request.headers místo v request.meta. To je překvapivě běžná chyba s malou odchylkou od správného zápisu — HttpProxyMiddleware čte jen meta["proxy"] a pokus přes header tiše selže bez zjevné chyby.
• Chyba: Předpoklad, že HTTP a HTTPS proxy se konfigurují stejně. URL HTTP proxy směrující na HTTPS cíl obvykle funguje přes CONNECT tunneling v kompatibilním handleru, ale použití schématu https:// pro samotný proxy endpoint je jiná a méně podporovaná konfigurace — neplést si to.
• Tip: Pokud potřebujete podporu SOCKS5, nejdřív zkontrolujte možnosti download handleru ve vaší verzi Scrapy. Experimentální HttpxDownloadHandler ve Scrapy 2.17 přidal podporu SOCKS5 přes httpx[socks], ale pořád je označený jako experimentální — nebudujte na tom produkční závislost bez vlastního testování.

Alternativní postupy

Kromě scrapy-rotating-proxies některé týmy směrují veškerou proxy logiku přes gateway poskytovatele — tedy jednu proxy URL, kde vendor v zákulisí řeší rotaci, session stickiness i geo-targeting. Tím trochu obětujete kontrolu, ale výrazně si zjednodušíte middleware kód, a stojí za to si to nacenit proti vlastnímu poolu, než začnete stavět od nuly.

Závěr

Nastavit proxy v Scrapy zabere jeden řádek. Udržet to v provozu v reálném produkčním crawlu ale vyžaduje jasnou politiku chyb, chráněné credentials, otestované hranice handlerů a selector, který při retry záměrně přepisuje zkopírovaná proxy metadata. Kdybyste si z článku odnesli jen dva návyky, ať jsou to tyto: fail-closed, když je proxy nutná, a nikdy necommitujte proxy heslo do Python souboru.

Často kladené otázky

Jak nastavím v Scrapy vlastní proxy s autentizací?
Použijte formát URL protocol://username:password@host:port, ale pokud uživatelské jméno nebo heslo obsahuje speciální znaky, nejdřív je percent-encodeujte pomocí urllib.parse.quote(). Pro produkci tato credentials načítejte přes classmethod from_crawler z environmentálních proměnných, ne natvrdo do kódu.

Jaké číslo priority mám použít pro vlastní proxy middleware v Scrapy?
350 je běžná priorita pro selector, protože běží před HttpProxyMiddleware na 750. Nezaručuje to rotaci. Retry dostane novou proxy jen tehdy, když selector pozná zkopírovaný retry request a přepíše jeho předchozí hodnotu meta["proxy"].

Jak v Scrapy automaticky zacházím s mrtvými proxy?
Postavte middleware, který v process_response a process_exception sleduje počet selhání na jednotlivé proxy, po překročení prahu je vyřadí z aktivního poolu a po ochlazovací periodě je vrátí zpět místo trvalého banování.

Můžu ve Scrapy používat SOCKS5 proxy?
Experimentální HttpxDownloadHandler ve Scrapy 2.17 dokumentuje podporu SOCKS5, pokud je nainstalované httpx[socks]. Výchozí HTTP/1.1 handler SOCKS proxy nepodporuje. Před tím, než tuhle cestu označíte za produkční, připněte verzi handleru a otestujte integračně.

Kolik může přístup proxy až při retry reálně ušetřit na nákladech?
Neexistuje žádné přenositelné procento. Změřte podíl autorizovaných požadavků, které vrací platný obsah přímo, množství dat přes jednotlivé proxy vrstvy, počet retry na úspěšný záznam a přidanou latenci. Pozorované snížení provozu přes proxy je vaše úspora; pokud přímý přístup není autorizovaný nebo nevrací validní data, tenhle pattern nepoužívejte.