A SOCKS5 proxy is a general-purpose tunnel that relays raw TCP (and UDP) traffic between a client and a destination without reading or modifying the traffic's contents — unlike an HTTP proxy, which operates at the application layer and understands HTTP requests and headers specifically.
An HTTP proxy sits at the application layer: it parses HTTP requests, can rewrite or add headers, and can cache responses, which makes it purpose-built for web traffic but limited to it. A SOCKS5 proxy sits one layer down, at the session layer, and simply forwards whatever bytes arrive without inspecting or altering them — it doesn't know or care whether the traffic is HTTP, an FTP transfer, or a game's UDP packets, which is why it works for non-HTTP protocols an HTTP proxy can't carry at all.
That pass-through behavior also affects the anonymity profile: because a SOCKS5 proxy never touches headers, it can't add the telltale proxy-identifying headers (X-Forwarded-For, Via) that a misconfigured HTTP proxy sometimes leaks, and a target site sees only the proxy's own IP with fewer structural clues that a proxy sits in front of the request.
For plain web scraping, an HTTP proxy is usually the better default: it matches the protocol the target actually speaks, integrates directly with every major scraping library's proxy configuration, and its header-rewriting ability is a feature, not a limitation, when a scraper wants to set or normalize its own headers. SOCKS5 earns its place when a workflow needs to tunnel non-HTTP traffic through the same proxy pool — some headless-browser setups route all of a browser's traffic (WebSocket connections, DNS, non-HTTP APIs a page calls) through one SOCKS5 endpoint rather than juggling separate HTTP and non-HTTP paths.
In practice, most production scraping stacks default to HTTP proxies for the request layer and reach for SOCKS5 only when a specific browser-automation or non-HTTP integration requires a single tunnel that doesn't care what protocol runs over it.
import requests
# pip install "requests[socks]"
proxies = {
"http": "socks5h://user:pass@proxy.example.com:1080",
"https": "socks5h://user:pass@proxy.example.com:1080",
}
# socks5h (not socks5) resolves DNS through the proxy, not the local machine
response = requests.get("https://example.com", proxies=proxies, timeout=15)How Crawlora handles this
Crawlora's proxy layer routes requests over whichever transport a target actually needs, so this is an implementation detail handled internally rather than a protocol choice you have to make yourself — the API abstracts it away along with IP-type tiering and rotation.
Related reading
Glossary
FAQ
It can leak fewer structural clues since it never touches headers, so there's no risk of a misconfigured proxy adding an X-Forwarded-For or Via header. But anonymity mostly comes from the underlying IP's trust level (residential vs. datacenter), not the protocol — a datacenter SOCKS5 IP is still a datacenter IP to a target's ASN check.
HTTP proxies are the better default for plain web scraping — they match the protocol targets actually speak and integrate directly with scraping libraries. Reach for SOCKS5 when a workflow needs to tunnel non-HTTP traffic, like routing an entire headless-browser session's WebSocket and DNS traffic through one proxy.
Yes — both support configuring a SOCKS5 proxy at the browser-launch level, which routes all of that browser's traffic, not just HTTP requests, through the tunnel — useful when a page's JavaScript opens WebSocket or other non-HTTP connections you also want proxied.
Beyond SOCKS5 Proxy, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.