The single biggest factor is whether your traffic is encrypted. On plain HTTP, the proxy can read everything. On HTTPS, it sees metadata, not the content. Send anything over plain HTTP through a proxy and the proxy is a full middleman. It can read the URL, the headers, the body, and any password you submit (ProxyVero). Send it over HTTPS and TLS encrypts the content before it leaves your device, so the proxy relays sealed packets it cannot open (Google Cloud). Most sites use HTTPS now, so in practice this is the common case.

What it can see on HTTPS

Even with encryption, some information is not hidden. The proxy can still observe the destination IP address, the destination hostname (the SNI field is sent in plaintext during the TLS handshake unless Encrypted Client Hello is in use), your DNS lookups if they route through it, and the timing, frequency, and size of your connections (Industrial Monitor Direct). What it cannot read on HTTPS is the URL path, the headers, cookies inside the session, form data, passwords, or the page content (ProxyVero). So it knows which host you reached and when, but not what you did there.

What it knows no matter what

A proxy is the party relaying your packets, so a few things are true by design. It sees the real IP address you connect from, it knows your account, and it can tie every session back to you. Depending on its logging policy, it can also keep records of all of that. Encryption hides the content, not the fact that you connected to a given host at a given time. A residential proxy adds one more observer, because your traffic exits through a stranger's device, so that exit node sits on the path as well.

The only way it reads your HTTPS content

There is one exception to the metadata rule, and it is TLS interception. A proxy can read encrypted content only if it terminates TLS with its own certificate and then re-encrypts, and that requires your device to trust its root certificate. On a managed work device this is sometimes configured by the employer. For a proxy you set up yourself, it cannot silently decrypt your HTTPS unless you installed its certificate. If a provider asks you to install a root certificate, that is the point to stop and understand what you are agreeing to.

How to limit it

• Use HTTPS for everything. Never send anything sensitive over plain HTTP through a proxy, because that content is fully readable.
• Do not install a provider's root certificate unless you accept that it can then read your HTTPS content.
• Confirm no interception is happening by checking that the certificate you receive is the site's own, for example with openssl s_client or curl -Iv.
• Keep identities separate. Do not log into personal accounts over a scraping or work proxy, and avoid sending personal data you do not need to send.
• Read the logging and retention policy and the provider's jurisdiction before you route sensitive work through it. The provider sees the same live metadata either way, but how much it stores varies.
• Recognize the limit. The destination host is visible to any relay you route through, so a single proxy cannot hide which sites you visit from the provider itself. For that you need a different design, such as chaining through Tor.

Have you read your provider's logging policy, and do you route only over HTTPS? Has a provider ever asked you to install a certificate, and did you do it?