Skip to main content
Use this tutorial to configure a proxy, request an authorized public page, parse its fields, and export files. Validate the flow with example.com, then substitute an approved target and your operational contact address. Follow the target’s published request limits.

Choose a proxy and session

A proxy selects the network exit. You still need request limits, reliable selectors, and record validation. HTTP 200 alone does not establish that the collected fields are complete.

Collect and export with Requests

1

Create a Python environment

Run these commands in a new working directory. SOCKS proxies need the optional dependencies included in requests[socks].
On macOS or Linux, activate with . .venv/bin/activate. Download web_scraping.py and retry_after.py, and save both files in the same directory.
2

Set the target and proxy connection details

The following values are placeholders. Inject the complete proxy URL into SCRAPING_PROXY_URL. Match the protocol, host, port, and authentication details to the proxy you extracted. Use http:// for an HTTP proxy or socks5h:// for a SOCKS5 proxy. Percent-encode special characters in the URL’s username and password.
Inject real credentials through your secret-management tool for production tasks. Keep them out of shared scripts and logs. Update ALLOWED_HOSTS when changing the target; the example allows only approved HTTPS hosts on the default port. Replace contact@example.com in the script with your operational contact address.
3

Save the complete scripts

The main script reuses one requests.Session, sets the proxy for both HTTP and HTTPS requests, extracts the first title and h1, and verifies nonempty fields before exporting JSON and CSV. It disables automatic redirects to prevent an unchecked target change.
4

Run and inspect the results

After a successful run, open output/results.json and output/results.csv. Check the url, title, and h1 values, encoding, and record count. The console’s outcome=success reflects your actual run. Apply your duplicate-record rules before sending data to another system.

Use Scrapy

This single-file spider sets the proxy through an actual request’s meta["proxy"]. Its downloader middleware also routes auxiliary requests, including robots rules, through that proxy. This path uses Scrapy’s HttpProxyMiddleware, so provide an HTTP or HTTPS proxy URL. Save scrapy_example.py beside retry_after.py, and reuse the environment variables above.
scrapy_example.py
The spider uses asynchronous start(), robots rules, AutoThrottle, and per-domain concurrency limits. Middleware checks every response for authentication failure, 429, and the listed transient server errors, including auxiliary requests such as robots.txt. Rate limits or transient errors report a UTC retry_at, set a stop flag, and schedule crawler closure. Subsequent requests are rejected so an external scheduler can resume later. Automatic retries and redirects are disabled to prevent another component from resending too early. Raw framework logs are disabled; the console reports defined error categories and actual export results.

Control retries and handle failures

The Requests example makes at most 3 attempts per URL. Its connect and read timeouts are 10 and 30 seconds, and its cumulative retry waiting budget is 60 seconds per task. This budget limits how long the current process waits; it does not shorten a valid Retry-After to 60 seconds. The header can contain seconds or an HTTP date. If its delay exceeds the remaining budget, or the last attempt still returns a transient error, the script reports outcome=deferred, a UTC retry_at, and a reason, then exits with code 2. Only missing or invalid headers use bounded exponential backoff. Resume at or after retry_at; the example does not create a schedule.

Validate before adding a task queue

Start with one authorized request and separately check the actual exit region. Inspect both output files for fields, encoding, and duplicate handling. Use controlled responses to test 407, 429, HTTP dates, and timeouts, and confirm deferred tasks do not retry early. Production tasks also need a queue, target rules, rate limits, session ownership, record validation, and isolation for parsing failures. Keep timestamps, status categories, and durations in logs while excluding proxy credentials. Increase concurrency only after valid-record rates, target responses, and costs satisfy your task constraints. For proxy configuration, see Requests documentation and Scrapy HttpProxyMiddleware. Header formats are defined in RFC 9110: Retry-After.