Tools
SOCKS5, and why there is no SOCKS port here
SOCKS5 is a transport-layer proxy protocol. Your client opens a TCP connection to it, asks it to connect somewhere, and from that point the proxy moves bytes without caring what they mean. That indifference is what makes it useful, and it is also why this service does not speak it.
What we do not offer
There is no SOCKS5 endpoint here, and no SOCKS4, no host:port proxy string, no username-and-password proxy authentication and no UDP. The only way to reach a target through us is an HTTPS API call. If your tool can only be pointed at a proxy address and cannot make an HTTP request of its own, it will not work with us — a design decision rather than a gap in a roadmap, and cheaper to learn on this page than after an afternoon of configuration.
What SOCKS5 actually does
The client connects, negotiates an authentication method, then sends a request naming a destination host and port. The proxy opens that connection and relays in both directions. It never parses what flows through, which is why one SOCKS5 proxy carries HTTP, mail, a database wire protocol or an SSH session equally well.
Remote DNS
The destination can be sent as a hostname, so the name is resolved at the proxy rather than on your machine.
UDP too
The protocol defines a UDP association alongside ordinary connections, which is why it turns up wherever UDP must be carried.
No encryption of its own
SOCKS5 authenticates the client and then relays. Whatever privacy you get comes from the protocol running on top, usually TLS.
When a transport proxy is the only thing that will do
Look for a SOCKS5 provider rather than for us if your work is any of these: something that is not HTTP at all, such as mail, IRC or a database client; a tool whose only network setting is a proxy address, which describes a great many desktop and command-line programs; anything needing UDP; or routing a whole process without touching its code, which is what ssh -D and its equivalents exist for.
None of that is exotic. It is the reason the protocol was written, and a fetch API is not a substitute for any of it.
What we are instead
One HTTPS call. POST /v2/proxy/fetch?region=us-east with an x-api-key header and a JSON body naming the URL. An egress node in that region makes the request and hands back the target's response in a JSON envelope. Region is a query parameter chosen per request; the values today are us-east, us-west and europe.
Nothing is configured anywhere. No proxy setting in your HTTP client, no per-language proxy plumbing, no NO_PROXY list to maintain, and no environment that locks you out because proxy variables are unavailable there.
What an API hands back that a tunnel cannot
A relay has nothing to tell you; moving bytes is the whole of what it knows. An API call returns a description of the fetch alongside the body — the target's own status code, the content type it declared, where the request landed and how many redirects it took, the egress address the target saw, the region that served it, the byte count and the elapsed time.
Two of those earn their place. region_used is the region that actually served, which is not always the one you named: a region whose node fails mid-request is failed over to another, and that field is how you find out. And because a call is one metered unit of work, an Idempotency-Key makes a retry after a timeout neither re-executed nor billed twice, with Idempotency-Replayed: true on the replay. A byte relay has no unit of work to make idempotent.
What you give up, plainly
HTTP and HTTPS URLs are the entire surface, fetched with a GET. There is no request body, no Authorization pass-through and no cookie jar, so a target needing a signed header, a login or a POST is out of reach. Code that expects to set a proxy has to be changed into code that makes an API call — a small change, but a change, and it is yours to make.
You also get a complete response rather than a stream: the node fetches under size and timeout caps and returns an envelope. And there is no opaque tunnel, because there cannot be one — our node terminates TLS with the target and reads the response before packing it up. Nodes do not log target URLs or bodies, but that is a commitment you are trusting rather than a property of the protocol.
Questions
- Can I point my SOCKS client at your addresses?
- No. The egress nodes accept only HMAC-authenticated calls from our own API and refuse everything else. A node anyone could connect to would be an open proxy, which is both an abuse problem and a fast route to having the address blocklisted.
- Is SOCKS5 more private than an HTTP proxy?
- Not by itself. SOCKS5 adds no encryption; it simply does not read or rewrite what passes through, where an HTTP proxy may add or alter headers. Privacy on either comes from TLS and from what the operator logs, not from the proxy protocol.
- Will SOCKS5 be added later?
- It is not planned. The metering, the idempotent retry and the response envelope all depend on a request being a discrete unit of work, and a transport proxy has no such unit. Adding one would be a second, different product rather than a setting.
- My scraping library takes a proxy URL. What do I do?
- Call our API directly instead of configuring a proxy. It is an ordinary HTTPS POST with one header and a one-field body, and the code examples page shows it in curl, Python and JavaScript.
Get a key
Create an account and mint an API key in the dashboard. The full endpoint reference — request shapes, parameters and error codes — is published at https://api.roamingproxy.com/v2/docs.