What exactly is recorded in a Nodetonet audit log?

Each accepted TCP connection produces one row at close time containing: timestamp, proxy ID, client ID, source IP, target hostname, target port, bytes in/out, connection duration, outcome status, and the egress IP seen by the target. URL paths, headers, cookies, and payload content are never recorded.

How long are audit logs kept?

By default, log rows are kept for 30 days and then dropped automatically. If you need longer retention for compliance or billing audits, you can enable extended logging per proxy, which stores rows for a longer window than standard logging.

Can I see which customer used my proxy and how much bandwidth they consumed?

Yes, but only if you create separate per-customer proxy clients. Without separate clients every connection logs with clientId=null. Once clients are set up you can query bytes per client per day from the Connection log tab or via the API. See the proxy clients post for setup details.

Does Nodetonet log the content of my requests?

No. Nodetonet records only connection metadata — source IP, target hostname, bytes, duration and outcome. URL paths, query strings, HTTP headers, request and response bodies, and cookies are never recorded. HTTPS traffic is encrypted end-to-end between your client and the destination, so the content is technically inaccessible at the proxy layer regardless.

How do I detect a brute-force attack on my proxy credentials?

Filter the Connection log to status=auth_failed and group by source IP. A sustained stream of failures from one IP — especially at a high rate over a short window — is a strong sign of a credential spray. Once identified, add that IP to your deny list. See the IP allow/deny lists guide for the one-click block flow.

Am I responsible for the audit logs under GDPR if I resell proxy access?

Yes. If you resell access to end users, you become the data controller for any personal data in those logs — primarily the source IP addresses of your customers. Your privacy policy must disclose that connection logs exist and state the retention period. Nodetonet acts as a data processor on your behalf and does not share or analyse your logs across accounts.

Can I delete audit log data to comply with a GDPR erasure request?

Yes. You can wipe a proxy's entire log history from the Connection log tab at any time — deletion is immediate and irreversible. For selective deletion of a single user's source IP across an extended period, contact support@nodetonet.com with the proxy ID, client ID, and the IP address to be erased.

Audit logs — who used your tunnel, when, and to where

If you resell proxy access, run scrapers on behalf of paying customers, or just want to know whether someone is brute-forcing your SOCKS5 password at 3 AM, you need an audit trail. Nodetonet keeps one for every tunnel and every proxy. This guide explains exactly what gets logged, where it lives, how long it is retained, how to query it from the panel or the API, and — equally important — where we deliberately chose not to record.

TL;DR: every accepted TCP connection produces one log row at close time: source IP, target host, bytes, duration, status, and egress IP. URL paths, headers, cookies, and payload content are never recorded.

What the audit log records

Every accepted TCP connection through any of your proxies produces a single row when that connection closes. The row contains the following fields:

ts — UTC timestamp at millisecond precision, recorded when the connection closed.
proxyId — which of your proxies handled the connection.
clientId — which per-customer proxy client credential authenticated; null if the proxy uses shared credentials with no separate clients.
srcIp — the public IP that connected to the edge. IPv4 or IPv6.
targetHost — destination hostname, sourced from SNI for HTTPS, the CONNECT header for HTTP, or the SOCKS5 request for SOCKS5 proxies.
targetPort — destination port number.
bytesIn / bytesOut — wire bytes in each direction, including TLS framing.
durationMs — total connection lifetime in milliseconds.
status — outcome: ok, auth_failed, blocked_by_acl, upstream_err, or timeout.
egressIp — the IP the request appeared from at the target — the paired mobile device's carrier IP, your upstream exit, or the edge server IP depending on proxy type.

What is deliberately not recorded

The fields above are everything. What is not in the log: URL paths, query strings, HTTP headers, request bodies, response bodies, cookies, response status codes, or any decrypted payload. The HTTPS pass-through architecture used by mobile proxies and HTTP tunnels means TLS is terminated at the client's device, not at the edge, so we cannot inspect the payload even if we wanted to. On plain-HTTP proxies we also deliberately avoid capturing it.

This is the same design choice described in the SSL pinning and your proxy post: a proxy that cannot see your traffic cannot leak it.

Where logs live and how long they are kept

Audit rows are written to a ClickHouse cluster, partitioned by date and indexed on proxyId and clientId for fast per-proxy and per-client queries. Default retention is 30 days; rows older than that are dropped automatically. If you need longer history — for compliance, billing disputes, or security investigations — enable extended logging on a per-proxy basis. Extended mode keeps rows for a longer window than standard logging.

Log fields at a glance

Field	Type	What it tells you	Privacy sensitivity
`srcIp`	string	Who connected to your proxy	High — personal data under GDPR
`targetHost`	string	Which site or service was reached	Medium — reveals browsing pattern
`egressIp`	string	IP the target site saw	Low — your own exit IP
`bytesIn/Out`	integer	Bandwidth used per connection	Low — no payload content
`status`	enum	Success or failure reason	Low
`durationMs`	integer	How long the session lasted	Low

Querying logs from the panel

Open any proxy on the panel and scroll to the Connection log tab. The default view shows the past 24 hours. You can filter by:

Client — narrow to a single per-customer credential.
Target host — prefix matching, so a filter like *.cloudflare.com matches all Cloudflare destinations.
Source IP — useful for tracing a single user or flagging an abusive source.
Status — filter to auth_failed only to spot credential attacks instantly.

You can group results by host, client, or hour to get bar-chart breakdowns. For bulk exports, switch to the CSV download — the panel keeps the same filter parameters, so you get exactly the slice you are looking at.

Querying logs via the API

The same data is available programmatically. Use your API key and the endpoints below:

# last 24 hours of activity for one proxy
curl -H "Authorization: Bearer $KEY"   "https://nodetonet.com/api/v1/proxies/<id>/logs?from=24h"

# CSV export of the last 7 days, scoped to one client
curl -H "Authorization: Bearer $KEY"   "https://nodetonet.com/api/v1/proxies/<id>/logs.csv?from=7d&clientId=<cid>"

# bytes per client per day (billing reconciliation)
curl -H "Authorization: Bearer $KEY"   "https://nodetonet.com/api/v1/proxies/<id>/usage?groupBy=client,day"

For a broader introduction to the REST API, see your first API call.

The three queries you will actually use

Most operators spend 90 percent of their log-review time on three questions:

Bytes per client per day. This is the top billing-audit query. A single client suddenly burning many times its normal volume is either abusing your service or running a misconfigured loop. Zero bytes for a client that should be active means a broken integration. Gradual creep across all clients means your pricing or quotas need revisiting. Pair this insight with hard quota limits per client to turn observation into enforcement.
Auth failures per source IP. This catches credential spraying before it succeeds. A handful of auth_failed events from one source in a short window is normal; a sustained stream is worth a manual look and possibly an entry on your IP deny list.
Distinct target hosts per client. A scraping customer might legitimately hit thousands of hostnames; a personal-use client hitting thousands is suspicious. This query pairs well with domain restrictions when you want to lock a client to approved targets only.

Privacy, GDPR, and your obligations

The audit log exists to protect the account owner — you — not to surveil end users. If you resell access, you are a data controller for those logs under GDPR; communicate that clearly to your customers.

Source IP addresses are personal data under GDPR for EU operators. If you sell proxy access to end users — whether through the reseller or white-label programme or a custom offering — your privacy policy must disclose that connection logs exist and state the retention period. Nodetonet does not share or analyse your logs across accounts; each account's data is isolated. You can wipe a proxy's complete log history from the panel at any time. We respond only to lawful, properly scoped subpoenas from competent authorities.

If you are running an automated scraping service for clients, the rotating mobile proxies post covers the traffic-pattern considerations that keep your egress IPs healthy alongside your logging practice.

Deleting log data

You can delete a proxy's full log history from the Connection log tab at any time. Deletion is immediate and irreversible — rows are removed from ClickHouse rather than soft-deleted. If you need selective deletion (for example, to honour a GDPR erasure request for one end-user's source IP), contact support@nodetonet.com with the proxy ID, client ID, and the IP address to be erased.

What to set up alongside logging

Per-customer proxy clients — without separate clients every user shares the same clientId=null row; split them so audit results are attributable.
Quota limits per client — turns the byte-per-day insight from the log into an automated hard cap.
IP allow/deny lists — act on sources you identify in the auth-failure report.
Domain restrictions — lock clients to an approved list of target hosts.
Proxy checker — verify that your proxy is reachable before blaming the logs for missing rows.