Skip to main content

Protocol by Service

Datacenter and ISP

The tables in the sectionsbelow details TLS and specific protocol version support across each of these product lines.
ProtocolSupportedCleartext to ProxyHTTP to ProxyHTTP to Target
SOCKS5
HTTP/1
HTTP/2
HTTP/3
Our Datacenter and ISP proxies support SOCKS5, HTTP/1 and HTTP/2. We do not provide IP based TLS certificates so all communication with the proxy must be cleartext. This does not mean your traffic is unencrypted. You will still do TLS to the target as long as your target supports TLS.
For HTTP/2, these product ranges only support HTTP/2 Prior Knowledge.

Residential

We do not support HTTP targets on our residential network to protect user security. You must ensure you are connecting to HTTPS targets via port 443.
ProtocolSupportedCleartext to ProxyHTTP to ProxyHTTP to Target
SOCKS5
HTTP/1
HTTP/2
HTTP/3
Our Residential proxies support SOCKS5, HTTP/1, HTTP/2 and HTTP/3. We provide TLS certificates for our residential backconnects so all communication with the proxy can be encrypted - inlucding SOCKS5 if you so desire. Unlike competitors we support HTTP upgrades via ALPN. Simply set your proxy string to use the “HTTPS” scheme and your client will do the rest of the work, upgrading you to the best protocol for the job under the hood.
For HTTP/2, we support Prior Knowledge and ALPN upgrades. We do not support HTTP/1 upgrades to HTTP/2 for security reasons.

HTTP Method Support

All of our HTTP capable products - regardless of version - support two types of usage.
  • Firstly, using the CONNECT method which establishes a TCP tunnel to your target.
  • Secondly as a man in the middle (MITM) proxy, which reads your requests and forwards them to your target.
The MASUQE working group have defined two new HTTP methods “CONNECT-UDP” and “CONNECT-IP” for tunneling UDP and IP traffic respectively via a HTTP connection. These methods are valid for all HTTP versions. We are actively contributing to our open source libraries to support these methods.
CONNECT tunnels should be used in the majority of cases but especially when connecting to a TLS capable target. Any TCP based protocol can be spoken over a CONNECT tunnel, you aren’t limited to HTTP traffic only. As mentioned above, we can’t see any of your traffic when using a CONNECT tunnel to a TLS capable endpoint. When acting as a MITM, your requests are forwarded with minimal changes (we strip proxy specific headers). MITM proxies can be used to send requests to both cleartext and TLS capable endpoints. When communicating with a TLS capable endpoint and using as a MITM proxy, we can see the contents of your requests. If you do not desire this, use a CONNECT tunnel.
MITM proxy requests sent to TLS capable endpoints might be modified for compatability with the target. If you send us HTTP/2 but the target only supports HTTP/1, we will adjust the protocol version.
Typical proxy clients follow this simple rule: HTTPS requests go through a CONNECT tunnel, HTTP requests are sent MITM-style. We support other use-cases so that when writing your own clients, we can fit any use-case.
I