HTTPS targets, and why this is not a CONNECT proxy

Two connections, not one tunnel

Your client opens an HTTPS connection to api.roamingproxy.com. The egress node then opens a second, separate HTTPS connection to the target. Both legs are encrypted, and neither is a tunnel through to the other: the node terminates TLS with the target and sees that response as plaintext before packing it into the envelope that comes back to you.

That is inherent to a fetch API and you should know it before you decide what to send through one. What we do about it is narrow and checkable: nodes do not log target URLs or response bodies. Metering records request counts and byte counts, because that is what an invoice needs, and the content is not part of that record.

Certificates are verified

The node verifies the target's TLS certificate. A target with an expired, self-signed or mismatched certificate fails rather than being fetched anyway. There is no flag to turn that off, because the flag would exist mainly to be left on by accident.

The refusal comes back as upstream_unreachable — deliberately the same code you get for a connect failure or a protocol error, with the same body text. That is coarse on purpose. A detailed error would tell a caller the difference between a host that does not resolve, a host that refuses the connection and a host with a bad certificate, and that difference is enough to map somebody else's network through us one probe at a time. The specific reason is logged on our side and not returned.

The practical consequence is that upstream_unreachable does not tell you which of those it was, and you should not build branching logic that assumes it does. If you need to know, check the target's certificate yourself from a machine you control — openssl s_client will answer in one command, and it is the right tool for that question anyway.

Why an API instead of a CONNECT proxy

A conventional HTTPS proxy is a host, a port and a CONNECT verb. It means per-language proxy configuration, proxy credentials living in your client, environments where you cannot set proxy variables at all, and no per-request record of what happened.

A single API call replaces all of that. Authentication is one header. Every request is metered exactly. You can send an Idempotency-Key so a retry after a timeout is not executed or billed twice. And the response tells you the egress address the target saw, the region that served it, the redirect count and the final URL — facts a CONNECT tunnel has no way to hand back.

What the outbound request looks like

The request the node makes to the target is a GET. It carries a small fixed header set — Accept, Accept-Encoding and Accept-Language — plus the User-Agent you set on your call to us. That is the entire allowlist of headers a caller can influence, and it is an allowlist by design rather than a pass-everything default that grows quietly.

So there is no cookie jar, no Authorization pass-through and no request body. A target that needs a signed header or a POST cannot be fetched today. Publicly reachable, GET-addressable URLs are what this serves.

Redirects are re-checked, not followed blindly

Redirect following is disabled in the HTTP client and implemented in the node instead, so each hop is validated after DNS resolution before the connection is made. A chain that starts at a public hostname and redirects toward a private address or a cloud metadata endpoint is refused at the hop where it turns, not after the fact.

Questions

Do you support SOCKS5?

No. This service speaks one thing: an HTTPS API you POST a URL to. There is no SOCKS4, SOCKS5, HTTP CONNECT or UDP surface. The page that used to advertise one now explains the difference instead.

Can I set my own headers on the outbound request?

Only the User-Agent today. The node keeps an explicit list of forwardable headers and it currently has one entry, which is what stops identity-bearing and hop-by-hop headers from leaking through.

Can I POST to a target through the proxy?

No. The outbound request is always a GET and the request body you send us contains only the URL to fetch. If you need to POST to a target, this is not the tool for it today.

Is my traffic end-to-end encrypted to the target?

No, and any provider telling you otherwise while also returning you the response body is describing something impossible. There are two TLS connections with our node in the middle. The node does not log the URL or the body.

Related