what a proxy provider can see about your traffic

a proxy is a machine you route your traffic through, operated by people you have never met. it is worth knowing what that machine is in a position to record, rather than reasoning from a policy page about what it promises not to.

the connect method draws the line

for https the client does not hand the proxy a url. it sends connect host and port, the proxy opens a tcp connection to that host, and after that it relays encrypted bytes it cannot read. the tls session is between you and the target, so the proxy holds the hostname, the port, the timing and the byte counts, and nothing inside.

bash

# everything the proxy is handed for an https request is on this one line
curl --proxy "$PROXY" -v "https://target.example/orders/8891?token=secret" 2>&1 \
  | grep -i '^> CONNECT'

# > CONNECT target.example:443 HTTP/1.1

plain http is a different situation and worth avoiding for anything you care about. there the client puts the whole url in the request line and the proxy performs the request itself, so it can read and rewrite every header, every path and the body.

dns is the part people forget

if your client resolves the hostname locally and then asks the proxy for an address, your own resolver, and your isp behind it, learns every site you visit. socks5 can carry a hostname instead, so the name is resolved at the exit. in curl the difference is one letter in the scheme.

bash

# socks5:  the name is resolved here, by your resolver
curl --proxy "socks5://$USER:$PASS@$HOST:1080" https://target.example/

# socks5h: the name travels to the proxy and is resolved at the exit
curl --proxy "socks5h://$USER:$PASS@$HOST:1080" https://target.example/

metadata is still a lot

not reading your traffic is not the same as knowing nothing about it. a gateway handles all of this by design, whether or not any of it is written down:

the hostname and port of everything you reach.
when each connection opened and closed, to the second.
how many bytes went each way, which is also how it bills you.
the address you connected from.
which account paid, and which exits that account was handed.

a list of hostnames with timestamps and sizes describes a job well enough to reconstruct what it was doing. that is why the retention question matters more than the encryption question.

questions worth asking a provider

what is written to disk per connection, and how long does it stay there.
what identity the account is tied to, and what was needed to open it.
whether the payment method attaches a name to that account.
who else can reach the machine holding any of it.
what happens to the records when the account is deleted.

notethe honest answer to the first question is never "nothing at all". a gateway has to count bytes to bill you and has to hold a connection to relay it. what a careful operator can do is keep the byte counter and drop everything that names a destination.

what you can shrink yourself

use https everywhere, so the tunnel carries encrypted bytes rather than readable requests.
resolve at the exit with socks5h, so your local resolver is not a second record of the same job.
keep credentials out of urls and query strings, since those land in your own logs as well as anyone else.
separate jobs across accounts when they should not be linkable, because one account is one billing record.
pay in a way that does not attach a name, if the account is the identity you care about.

none of this touches what the target sees. the site you fetch from still gets an address, a handshake and a header set, and it can link sessions on those alone. what happens in the middle of the path and what happens at the end of it are two separate problems.