HTTP & HTTPS Proxies

An HTTP proxy accepts web requests from your browser or application and connects to the destination on your behalf. It can carry ordinary HTTP traffic and, with support for the CONNECT method, encrypted HTTPS traffic. An HTTPS proxy adds encryption to the connection between your application and the proxy itself.

These are two separate choices: how your application reaches the proxy, and how it communicates with the website through that proxy. Understanding both helps you select the right connection settings. The broader choice between proxy protocols is covered in SOCKS vs HTTP Proxies.

What an HTTP proxy does with a web request

Suppose a monitoring script requests http://example.com/catalog. Instead of opening a connection to the website, it connects to the configured proxy. With HTTP/1.1, it sends the full destination URL in its request so the proxy knows which server and page to contact. The proxy sends the request onward and returns the website's response to the script.

In this mode, the proxy processes HTTP messages. It can read the method, such as GET or POST, the requested address, headers and any submitted data. Software configured for the purpose can apply access rules, record requests or cache eligible responses. Caching is an optional function governed by the response's caching rules; buying HTTP proxy access does not mean that every page will be cached.

The website receives the network connection from the proxy's exit IP. The term HTTP says nothing about where that IP comes from or how long it stays assigned. The same connection protocol can be offered with datacenter, ISP, residential or mobile addresses, using fixed IPs or a rotating pool.

On the left, CONNECT between the app and the HTTP proxy is readable on the network. On the right, the same request is hidden inside TLS to the HTTPS proxy. HTTPS website content is encrypted in both cases.

How an HTTP proxy opens an HTTPS website

An HTTPS website uses TLS to protect the exchange between the application and the website. To carry that exchange, an HTTP proxy first creates a tunnel. For a request to https://example.com/catalog, the sequence is:

Four steps: CONNECT to the proxy, a destination connection and tunnel confirmation, TLS certificate checks, then encrypted traffic.

The application connects to the proxy and asks it to open a tunnel to example.com:443, using the CONNECT method. The request names the destination host and port, without the page path.
The proxy checks whether access and the requested destination are allowed, including any required proxy authentication. It opens a connection to the destination and confirms that the tunnel is ready.
The application performs a TLS handshake with the website through the tunnel and checks the website's certificate.
The application sends its web request inside that TLS connection. The proxy relays the encrypted bytes in both directions.

The proxy does not have to read the page to deliver it. The application and the website remain the endpoints of the website's TLS connection. CONNECT supplies the tunnel; TLS supplies encryption and protects the exchange against undetected changes.

This is why an HTTP proxy can open an HTTPS website even when the proxy address begins with http://. The website's HTTPS protection operates inside the tunnel. It does not depend on having TLS between the application and the proxy.

What an HTTPS proxy adds

With an HTTPS proxy, the application first establishes TLS with the proxy and verifies the proxy's certificate. It then sends its HTTP requests, or its CONNECT request for a tunnel, inside that protected connection. A network observer between the application and the proxy cannot read those requests.

For an HTTPS destination, the application maintains two separate TLS connections: one with the proxy and one with the website through the tunnel. The proxy removes the outer protection addressed to it, but the website data inside remains encrypted. It forwards those bytes to the website, which can decrypt them. For an HTTP destination, there is no inner TLS connection: only the connection to the proxy is protected.

Connection to proxy	Destination	What is encrypted?
HTTP	HTTP website	Neither connection uses TLS. The request and response are readable along the route.
HTTP	HTTPS website	The website exchange is encrypted through the tunnel. `CONNECT` and proxy authentication have no TLS protection on the connection to the proxy.
HTTPS	HTTP website	TLS protects the connection to the proxy. The proxy can read the web request and forwards it to the HTTP website without TLS.
HTTPS	HTTPS website	TLS protects requests to the proxy, and separate TLS protects the website exchange carried inside the tunnel.

This comparison describes ordinary proxy forwarding with certificate checks enabled, without HTTPS inspection or a separate VPN. Encrypting the connection to a proxy does not upgrade an HTTP website to HTTPS.

What the proxy and the website can see

For an HTTPS destination, a forwarding proxy cannot read the page path, query parameters, cookies, form data or returned content inside the TLS connection. It still knows the client IP that connected to it, the destination host and port requested in CONNECT, and the timing and volume of traffic. TLS to the proxy keeps CONNECT private from observers on that part of the network, but not from the proxy that must act on it.

Proxy credentials are sent separately from a website login. Basic proxy authentication encodes the username and password using Base64, which can be decoded without a secret key. Over a plain HTTP proxy connection, this does not protect them from a network observer. The website's HTTPS connection starts inside the tunnel and does not cover the earlier proxy login. TLS to the proxy protects that login in transit.

At the other end, the website receives traffic from the exit IP and reads the requests addressed to it. It can recognise an account, a session cookie or other information the application sends. Choosing an HTTPS proxy does not remove those identifiers or automatically improve the website's acceptance of the exit IP.

HTTPS inspection is a different setup used in some managed networks and debugging tools. The application trusts a certificate authority controlled by the inspecting proxy, which can then read traffic while maintaining separate TLS connections on each side. Normal CONNECT forwarding does not require installing such a certificate. Trust in the HTTPS proxy's own server certificate is separate from permission to impersonate websites.

The app creates a GET request with a cookie. The proxy relays encrypted content without reading it; it knows the host and port from CONNECT. The website decrypts the request and reads its path and cookie. Ordinary HTTPS forwarding without interception.

How to read the connection settings

A proxy setting needs an address, a port, a connection protocol and any required authentication. The protocol in the proxy URL applies to the proxy. The protocol in the destination URL applies to the website.

These curl commands request the same HTTPS website through two different proxy connections. Replace the proxy hostname and port with the values supplied for the chosen connection method:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

The first command connects to the proxy over HTTP, then creates CONNECT and TLS to the website. The second creates TLS to the HTTPS proxy first, then carries the website's separate TLS connection through it. In either case, also provide the authentication required by the proxy service.

Simply changing http:// to https:// will not turn an HTTP-only port into a TLS endpoint. If the service supplies a hostname for HTTPS access, use that hostname: replacing it with an IP can cause a certificate name mismatch.

Labels in applications need the same careful reading. A field called “HTTPS proxy” may select the proxy for HTTPS websites while still connecting to it over plain HTTP. In curl, the variable HTTPS_PROXY also selects a proxy for HTTPS destinations; its value can correctly begin with http://. The label tells you which requests use the setting, while the proxy scheme tells you how the connection is made.

DNS and the traffic that goes through the proxy

When an HTTP client supplies a destination hostname, the proxy normally looks up its IP and connects to it. The client performs a separate lookup if it needs the proxy's own hostname to reach that proxy. A browser may also issue DNS queries for prediction or other features. These are separate lookups; setting a web proxy does not route every DNS request through it.

The setting applies to traffic that the application actually sends to the proxy. Another program may keep connecting directly, and an exception list may bypass the proxy for selected sites. For example, routing an API script through a proxy does not change the route used by an unrelated browser. Check the exit address from the application and configuration that will run the task.

The client resolves the proxy hostname. After receiving the website hostname, the proxy resolves it. Other applications or bypass rules can use a direct route.

HTTP/2 to the website and HTTP/2 to the proxy

HTTP/2 lets several exchanges share a connection using separate streams. With a proxy, it matters which connection supports it. An application can negotiate HTTP/2 with a website inside a tunnel created using HTTP/1.1 CONNECT. The proxy relays the encrypted bytes and does not need to understand the website's HTTP/2 messages.

HTTP/2 between the application and proxy is a separate capability. Each CONNECT tunnel uses its own HTTP/2 stream, so several tunnels can share one connection to the proxy. For example, tunnels to two different websites can use that connection while keeping separate destination connections and separate website TLS sessions. This reduces the need for additional client-to-proxy connections; it does not let the proxy read the encrypted website requests.

Both sides must support the chosen mode. HTTPS alone does not specify HTTP/2: an HTTPS proxy can use HTTP/1.1. Performance also depends on the client, network route, server load and reuse of connections. An HTTP/2 label is not a guaranteed speed increase for every task.

On the left, website HTTP/2 runs inside a TLS tunnel created with HTTP/1.1. On the right, two CONNECT tunnels use streams of one HTTP/2 connection to the proxy.

An ordinary CONNECT tunnel can also carry other TCP-based protocols if the application and proxy allow them, although destination ports may be restricted. It does not relay UDP. HTTP/3 uses QUIC over UDP, so it cannot travel through that TCP tunnel in the same way. HTTP-based UDP forwarding uses additional mechanisms such as CONNECT-UDP and requires compatible implementations. Support for HTTPS or HTTP/2 alone does not establish that support.

Where HTTP and HTTPS proxy access is useful

For browsing and website tests, an HTTP proxy with CONNECT supplies one connection method for both HTTP and HTTPS destinations. A team can use it to view a site from the proxy's network while keeping the browser responsible for page rendering, cookies and website logins.

For crawlers, API clients and scheduled monitors, an HTTP client can send requests through a chosen exit IP while keeping the destination URLs unchanged. The application still prepares requests and processes responses. Inside an HTTPS tunnel, the proxy carries that exchange without having to parse each page or API call.

A TLS-protected HTTPS proxy is useful when the connection to the proxy also needs protection, including the proxy login and destination requests. This matters when that connection crosses a network you do not control. The client must support TLS to the proxy itself; merely being able to open HTTPS websites is not enough.

Reading connection errors

A failure can happen while reaching the proxy, opening the tunnel or communicating with the website. The stage tells you more than the error code alone.

What happens	Where to look
The proxy returns 407	The proxy has requested authentication. Check its credentials or required access method; the website account is a different login.
HTTP works, but HTTPS does not	Check whether the client uses the expected proxy for HTTPS, whether `CONNECT` is allowed and whether the destination port is permitted.
A TLS or certificate error appears	Identify whether it comes from the proxy connection or the website connection. Check the relevant hostname, TLS endpoint and certificate trust instead of disabling certificate verification.
A 403 response is returned	A refusal of `CONNECT` comes from the proxy. A 403 inside a successfully established, normally verified HTTPS connection is a website response. These are different stages and call for different fixes.

A completed tunnel and TLS handshake show that the connection path works. They do not guarantee that the website will accept a particular account, exit IP or request. A login challenge, CAPTCHA or request limit can therefore require attention at the website or application level even when the proxy is functioning.