HTTP proxy or HTTPS proxy? Check which connection uses TLS

Alex — Sat, 10 Oct 2026 12:31:57 +0000

An HTTPS page can load successfully while your proxy login travels without TLS protection. The website connection and the connection to the proxy have separate security properties.

This distinction matters when you configure a client, read a provider's “HTTPS supported” label, or investigate a TLS error. Start with two questions: does the destination use HTTPS, and does the proxy endpoint itself accept TLS?

How HTTP and HTTPS traffic passes through a proxy

For an ordinary HTTP website, your application sends the request to the proxy. The proxy contacts the website, retrieves the response and sends it back. It handles the request as HTTP, so it can read the requested page address, headers and any content sent with the request.

For an HTTPS website, the application first asks the proxy to open a connection to the destination, such as example.com:443. This request uses the HTTP method CONNECT. After the proxy accepts it, the application establishes TLS with the website through the resulting tunnel. TLS is the encryption used by HTTPS.

The proxy forwards the encrypted traffic in both directions. It does not need to decrypt the page to deliver it. The application checks the website's certificate, just as it would when connecting directly. CONNECT creates the tunnel; TLS protects the data sent through it.

HTTP describes the connection protocol, not the source or allocation of the IP address. HTTP access can be offered with datacenter, ISP, residential or mobile addresses, and with fixed or rotating exits.

HTTPS websites and HTTPS proxy connections

There are two different capabilities to distinguish when reading a proxy description or choosing a setting.

HTTPS website support means that the proxy can carry a connection to an HTTPS destination. An ordinary HTTP proxy can do this using CONNECT. Your application's conversation with the website is encrypted, but the initial request to the proxy is not.

An HTTPS proxy connection means that your application establishes TLS with the proxy itself. Requests to the proxy, including CONNECT and proxy authentication, travel inside that protected connection. When the destination is also HTTPS, its own TLS connection runs through the tunnel. The proxy removes the outer layer of encryption; the website's traffic inside remains encrypted.

These capabilities are not interchangeable. A service that lets you open HTTPS websites does not necessarily accept TLS connections on its proxy port. To use an HTTPS proxy connection, both the proxy endpoint and your application must support it.

HTTPS protects the website content in both cases. TLS to an HTTPS proxy additionally protects the connection to the proxy, including CONNECT and Basic proxy authentication. Ordinary CONNECT forwarding with valid certificate checks is shown; HTTPS interception is excluded.

What the proxy can see

The following comparison assumes normal forwarding without HTTPS interception, working certificate validation and no separate VPN or other encrypted tunnel. “Page content” includes the URL path and query parameters, request headers, cookies, submitted data and the response.

Connection to proxy	Destination website	Can the proxy read page content?	Can someone observing the network between you and the proxy read page content?
HTTP	HTTP	Yes	Yes
HTTP	HTTPS	No	No
HTTPS	HTTP	Yes	No
HTTPS	HTTPS	No	No

An HTTPS proxy therefore adds useful protection on the way to the proxy, but it does not turn an HTTP destination into an HTTPS website. The proxy still reads that HTTP request and sends it onward without HTTPS protection.

Even with HTTPS at both stages, the proxy operator sees the source IP of your connection, the destination requested in CONNECT, and traffic volume and timing. HTTPS hides the page contents from a forwarding proxy; it does not hide the fact that you used it. The website receives the connection from the proxy's exit IP, but can still recognise your account or cookies.

Proxy credentials need separate attention. With Basic authentication over a plain HTTP proxy connection, the proxy username and password are encoded, not encrypted. An observer on that connection can recover them even when the destination website uses HTTPS: proxy authentication happens outside the website's protected connection. TLS to the proxy protects this exchange and the CONNECT request. It does not make unrelated traffic, such as separate DNS requests, private.

HTTPS inspection changes the arrangement. If your application trusts a certificate authority controlled by an inspecting proxy, that proxy can establish separate TLS connections and read the traffic between them. This is used in managed networks and debugging tools. Ordinary CONNECT forwarding does not require installing a proxy's root certificate; disabling certificate checks is not a routine fix for connection problems.

Entering the right proxy settings

Use the proxy hostname or IP, port, protocol and authentication details supplied for the endpoint. The protocol in the proxy address describes how to connect to the proxy. The protocol in the website address describes the destination.

For example, this curl command requests an HTTPS page through a plain HTTP proxy:

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

proxy.example and port 8080 are placeholders to replace with your actual endpoint. The first http:// is intentional: curl connects to that proxy using HTTP, then uses CONNECT and TLS to reach the HTTPS website. Add the service's required authentication separately. In a graphical application, use its proxy username and password fields or the provider's permitted source-IP setting, as applicable.

Use https:// in the proxy address only for an endpoint that accepts TLS. Changing the prefix does not enable encryption on an HTTP-only endpoint. Copy the issued hostname when the provider specifies one for HTTPS access: substituting an IP address can cause a certificate name mismatch.

Interface labels can also mislead. A field called “HTTPS proxy” or “Secure proxy” may mean “the proxy to use for HTTPS websites.” It does not, by itself, prove that the application will encrypt its connection to the proxy. The endpoint scheme and the application's support determine that. Ports such as 8080 or 443 are conventions, not proof of a protocol.

Which traffic this setup covers

A browser or HTTP client's proxy setting covers the requests that application sends through it. It does not automatically route other programs or the whole computer through the proxy. Bypass rules can also send selected destinations directly. When checking the result, use the same application and configuration that will run the actual task.

An HTTP/1.1 CONNECT tunnel can carry an HTTPS session using HTTP/2 between the application and the website. The HTTP version used to talk to the proxy does not set the version inside that tunnel. HTTP/2 support on an HTTPS proxy's own connection is a separate capability.

CONNECT opens a TCP tunnel. It can carry protocols other than web traffic when the application and proxy allow it, but the provider can restrict destination ports. Ordinary CONNECT does not carry UDP. UDP proxying through HTTP requires a separate mechanism, such as CONNECT-UDP, supported at both ends. An “HTTPS supported” label does not establish UDP or HTTP/3 support.

When a connection fails

Identify which stage failed before replacing the proxy or changing protocols. A refusal from the proxy and a refusal from the website call for different fixes.

Symptom	What to check first
`407 Proxy Authentication Required`	Proxy credentials and the authentication method accepted by the endpoint. This is a proxy login problem, not the website's login.
HTTP pages load, but HTTPS connections fail	CONNECT support, the permitted destination port, and which proxy setting the application uses for HTTPS requests.
A TLS error appears immediately after changing the proxy address to `https://`	Whether that proxy port actually accepts TLS, then the proxy's certificate and hostname.
A certificate error appears after the tunnel opens	The website certificate and any HTTPS inspection affecting the connection. Keep certificate validation enabled.
The website returns a login page, CAPTCHA or access denial after TLS succeeds	The request has reached the destination. Review the site's response, account state and request behaviour; successful proxy transport does not guarantee access.

For browsing, scraping and API requests, HTTP proxy access with CONNECT supplies the route to HTTPS destinations. Choose a TLS-protected HTTPS proxy endpoint when you also need to protect the connection to the proxy, including its authentication and tunnel requests. That additional protection is the practical reason to distinguish the two.

Originally published in ProxyData’s guide to HTTP and HTTPS proxies. This adaptation was prepared with AI assistance.

Same proxy IP, lost login: which session expired?

Alex — Fri, 09 Oct 2026 07:23:44 +0000

A browser automation job can keep the same proxy exit IP and still lose its login. Before changing the proxy settings, separate two kinds of state: the exit assignment managed by the proxy service and the website session maintained by your client.

Two sessions with different jobs

A sticky proxy session asks the provider to keep an exit assignment for a task. A common implementation uses a session label in the proxy settings, although some services use a sticky port or a dashboard option. Use the format documented for that product; adding a parameter to the destination website URL does not configure the proxy.

The website session usually depends on cookies or authentication tokens. Keeping an IP does not store those values, send them on subsequent requests, or extend the website login. A client object named “session” may retain cookies and reuse connections, but its name does not enable sticky mode at the proxy provider.

For independent users, keep client state isolated as well as choosing the intended proxy assignment. Separate browser profiles or separate cookie stores solve a different problem from separate proxy session labels.

Diagnose the symptom before changing the timer

What you observe	What to investigate
The exit IP stays the same, but the website asks you to sign in again	Whether the client retained and sent the required cookies or tokens, and whether the website session expired.
The session label stays the same, but the exit changes after a pause	The provider’s idle timeout, maximum lifetime, exit availability, and whether routing settings changed.
Repeated requests show one IP on a single TCP connection	Whether the same assignment also survives new proxy connections. One reused connection alone does not establish sticky behavior.

These observations narrow the investigation; they do not prove a single cause. A valid website session may survive an IP change if the website permits it. Conversely, a stable IP cannot prevent logout caused by an expired session or missing cookie.

Test both kinds of continuity

Open several new proxy connections using the same supported session label and routing settings. Record the exit address and time.
Reproduce the pauses in the real job. Check both the provider’s maximum lifetime and its idle timeout.
Run the complete application workflow with its actual cookie or token storage. Confirm that the required state survives between steps.
If an interruption happens after a request that changes data, check whether the original action completed before repeating it.

Changing the proxy TTL cannot restore a missing cookie or an expired website login. Treat the proxy assignment and the website session as separate parts of the test.

Based on ProxyData’s Sticky Sessions guide. This technical note was prepared with AI assistance.

DEV Community: ProxyData