Proxy Logging and Privacy
A website may see a proxy IP instead of your own, while the proxy provider knows which customer account opened the connection. These are two different views of the same request. Changing the address visible to a website does not make your activity invisible to the company carrying it.
Proxy logging means keeping records of how the service is used: connections, destinations, traffic volumes, errors and, in some products, requests and responses. This article explains practices across the industry. As with other proxy provider policies, the details depend on the service. The final section describes how ProxyCompass handles service data.
What a proxy can see when connecting to an HTTPS website
Consider an illustrative auction: your application submits a €180 bid to https://bid.example/lot/218/bids. With an ordinary proxy tunnel, HTTPS protects the exchange between your application and the website using the TLS security protocol. The provider can see the connecting client’s IP, the destination bid.example:443 and the connection time; it can also measure the volume of data transferred. The full URL, selected lot, client action, bid amount, cookies and auction response stay inside HTTPS. With correct certificate verification and no interception, the provider cannot read them.
The domain can be disclosed before that encrypted exchange begins. HTTP CONNECT normally names the destination host and port. SOCKS5 can receive either a domain name or an IP address; if the application asks the proxy to connect by domain name, the proxy learns that name. A destination IP alone does not necessarily identify a particular website, since multiple sites can share it.
Plain HTTP is different: its headers, page path and content are available to a proxy carrying the request. SOCKS5 does not add encryption to an otherwise unencrypted application exchange. HTTPS through SOCKS5 retains its HTTPS protection; HTTP through SOCKS5 remains readable.
The website itself receives the decrypted request. It can read the login, cookies and form fields you send it, and recognize an existing account after a proxy IP change. HTTPS protects data in transit; it does not hide that data from its intended recipient.
Why some proxy providers require you to install a certificate
Some providers require clients to trust their own root certificate for particular services that inspect HTTPS traffic. This requirement comes from the provider, not the website being visited, and does not apply to all proxies. ProxyCompass does not require clients to install its root certificate.
With an ordinary HTTPS tunnel, the proxy cannot read the contents of requests and responses. If a service needs to check submitted data, apply rules to it or analyse website responses, it needs access to those contents. HTTPS inspection provides that access: the service decrypts traffic passing through it.
A root certificate is a digital document that an application uses as a basis for trusting other certificates. Adding the provider’s certificate to the trusted set lets the application accept website certificates issued by that provider. In inspection mode, the proxy presents one of these certificates instead of the website’s original certificate. Without the corresponding trust, normal certificate verification fails.
The proxy establishes two separate encrypted connections: one with your application and one with the website. Between them, it can read requests and responses. In the illustrative auction example, this exposes the full address https://bid.example/lot/218/bids, the lot number, the submitted €180 bid, cookies and the response accepting the bid. The provider can see what the client actually does on the website.
This requirement depends on the particular product, mode and access method. It may appear in services that automate website access or when traffic analysis is enabled in a proxy manager. The label “residential” or “datacenter” alone does not tell you whether it applies. Sometimes you only need to supply the certificate to one script; installing it for the whole system is unnecessary.
Installing a certificate does not, by itself, route all traffic through the provider. The access described here arises when requests pass through a service with inspection enabled. A certificate used only to verify the proxy’s own HTTPS address also does not mean that the contents of the connection to the target website are decrypted.
Being able to read data and saving it in logs are separate matters. The certificate helps explain who can access the connection’s contents, but says nothing about retention periods or staff access. Disabling certificate verification does not hide data from a service that decrypts it either.
Scraping APIs and remote browsers receive the content
With a Scraping API, you give the service a task: open this URL and return the page or extracted data. The service makes its own connection to the website and receives the response in readable form. It can do this without asking you to install a certificate, because it is the client fetching the page.
A provider-hosted browser works on the provider's machines. Pages, cookies and browser sessions are processed there, even if the connection you use to control the browser is encrypted. Depending on the product, your task may include full URLs, custom headers, cookies, form data and instructions for interacting with a page.
This access is necessary to perform the task. It does not establish that every page is archived or that employees routinely read customer results. It does mean that the product's rules for handling tasks and results matter: a promise covering ordinary proxy tunnels may not cover its API or hosted browser.
For a business, the sensitive information may be a list of products being monitored, a sequence of searches or a set of research targets. Even when all the source pages are public, the collection and the way it is used can reveal a commercial project.
What can appear in proxy logs
A provider can maintain several kinds of records. They need not be stored together: a connection can refer to an account number, while the email address, order and payment sit in other systems.
| Record type | Possible contents |
|---|---|
| Connections | Start time and duration, connecting IP, proxy IP used to reach the site, destination address or domain, ports and connection errors. |
| Usage | Transferred bytes, connection counts and totals for an account or billing period. |
| Account and access | Registration details, sign-ins, authorized client IPs, credential changes, orders and payment references. |
| Support and incidents | Tickets, attachments, website complaints and records of the investigation. |
| Requests and results | Full URLs, headers, request bodies or fetched pages, where the product can read them and its settings allow recording. |
These are possible categories, not a list that every provider necessarily collects. A service can process a value to open a connection without retaining it. It can also keep a total bandwidth counter without preserving a permanent record of every destination.
A log's client IP is the address of the device or intermediary connecting directly to the proxy. With a direct connection it is usually the customer's public IP; with another intermediary in front, it may be that intermediary's address.
What a no-logs claim actually covers
“We do not store the contents of your traffic” can coexist with records of target domains, connection times and usage. “We keep only usage totals” describes a different arrangement. A short no-logs label does not tell you which of these promises the provider is making.
Read the claim against the named data and product. Does it exclude page content, individual connection records, destination history or all three? Does it cover normal operation only, or also diagnostic logging? What remains in account, payment, support and abuse systems?
A RAM-only claim describes a storage method. It does not tell you whether information is sent to another system before the memory is cleared. Likewise, encrypted storage protects records against certain kinds of unauthorized access; it does not mean the provider cannot read them.
Labels such as private, dedicated or elite do not answer these questions. They describe other properties of the proxy. An IP-checking website can inspect the request arriving at that website, but cannot verify the provider's internal logging practices.
How logs help with faults, billing and abuse reports
Connection records can distinguish an authentication failure from a destination that did not respond. Usage totals help explain a consumed traffic allowance. A sudden change in connection patterns can also reveal a broken script or unexpected use of an account.
One useful distinction is a successful proxy connection versus a successful website request. A successful CONNECT response confirms that a tunnel opened. Inside it, the site can still return a CAPTCHA or HTTP 403. An ordinary tunnel does not read that encrypted response, so its connection result and the application's website result can differ.
The target website has another view. If it receives password-guessing attempts, it can report the requests, the proxy IP, the time and other connection details. If the provider has enough corresponding records, it can match the report to the customer account used for those connections. Learning a request path from the website’s complaint does not mean the provider decrypted the original HTTPS traffic.
A shared proxy IP does not prevent this matching. Detailed records can link an authenticated customer connection to the connection made to the website. Precise timestamps, including milliseconds where recorded, ports and the destination help distinguish concurrent connections. Rotating IPs can also remain linked to the same account. Changing or sharing an address does not erase the provider's records.
How long records remain
Connection logs, invoices, support tickets and scraping results can have different retention periods. A useful policy explains those periods by category, or states the conditions used to decide how long each category is needed.
The history visible in a dashboard is not necessarily the full storage period. If the interface shows only recent activity, that tells you what you can view there. It does not establish when internal records, incident files or backups are deleted.
Closing an account does not necessarily erase every associated record. Billing or incident records can remain where there is a lawful reason to retain them. Deletion from active systems and expiry of backup copies can also happen on different schedules.
Replacing a customer's name with an account ID does not make the records anonymous if the company retains the link between that ID and the customer. The relevant question is whether the remaining information can still be connected to an account or person.
Who can access the information
The existence of logs and permission to read them are different issues. Support may need connection errors, finance needs payment records, and a security team may need information about an incident. The privacy policy should explain access and sharing; security controls should limit access to the people who need it.
A reseller and the company operating the proxy network may hold different parts of the record. Payment processors, hosting companies and support platforms can also handle particular data. Check which companies are involved and what information they receive.
The country of a proxy IP does not, by itself, determine where customer records are kept or which legal rules apply to the provider. The contracting company, its processing arrangements and applicable law also matter. A provider may have to disclose retained information to authorities under a binding legal requirement. The applicable conditions should be read in its policy; there is no single worldwide rule for every proxy service.
Choosing privacy terms for your workload
For a project that must keep page content within your own application, the distinction between a normal HTTPS tunnel and a managed fetching service is material. A tunnel can keep the contents unreadable to the intermediary while still exposing connection metadata. A managed API can reduce your own development work, but it receives the task and the result.
Destination metadata can matter too. A list of domains, the timing of visits and their volume may reveal which businesses or markets a team is studying. Decide whether that information is sensitive before treating content encryption as sufficient protection for the project.
Finally, consider what you send to support yourself. A configuration file or network capture can contain proxy passwords, access tokens, cookies and request bodies that never appeared in the provider's traffic logs. Remove unrelated secrets before sharing diagnostic material.
Before starting work, establish what the chosen product can read, what it keeps, when those records are removed and who can receive them. Those details make a privacy policy useful for a real task.