Keep Factually independent
Whether you agree or disagree with our analysis, these conversations matter for democracy. We don't take money from political groups - even a $5 donation helps us keep it that way.
What timestamps and IP addresses does my ISP log when I use Tor?
Executive Summary
ISPs log the outermost connection details when you use Tor: your assigned public IP (which may be shared via NAT/CGNAT), the timestamp[1] for the TCP flow, the source port assigned, the remote IP/port of the Tor guard or bridge, protocol, and byte/packet counters — but they cannot see Tor’s encrypted inner circuit or the final destinations you visit through Tor. Multiple technical analyses and community Q&A show consensus that an ISP’s records will include the guard IP and connection timestamps but not the websites visited or the contents of packets [2] [3] [4].
1. What ISPs Actually Record — Raw Connection Evidence That Points to Tor Use
ISP logging practices commonly capture full NAT table entries and per‑flow metadata: the subscriber’s public IP address, the source port allocated, destination IP and port, transport protocol, byte and packet counts, and precise start and end timestamps. That means when you connect to Tor, your ISP will log a record showing a TCP (or TLS) session from your public IP/port to the IP/port of a Tor entry‑guard or bridge, including the time you initiated it and how long it lasted. These logs do not reveal traffic contents or the Tor circuit beyond the guard because Tor encrypts inner layers; the ISP therefore only sees the outer connection to the Tor network [2] [3].
2. What ISPs Do Not See — Encryption, Circuits, and Final Destinations
Tor’s design forces the ISP to stop at the network’s edge: the ISP cannot inspect the inner encrypted layers to learn the final destination or the application‑level URLs. The consensus across technical answers is clear: ISPs cannot see which websites or services you visit inside Tor, because the Tor client negotiates encrypted circuits and the inner hops are not visible to the ISP that only sees the guard hop. DNS leakage is a separate risk for non‑Tor traffic, but properly configured Tor clients perform DNS resolution through the Tor network, preventing ISPs from learning resolved hostnames for Tor‑routed traffic [3] [5].
3. How ISPs Can Use Metadata — Timing, Volume, and Inference Risks
Although content is hidden, metadata retained by ISPs — precise timestamps, session durations, and byte counts — permits traffic‑analysis inferences. Observers with access to logs at both ends of a Tor circuit or to network backbones can correlate timing and volume patterns to deanonymize users in some scenarios; researchers and documentation note that packet sizes and frequency may leak signals that support correlation attacks. ISPs can therefore reliably prove a subscriber connected to the Tor network and when, and they may be able to infer session patterns or throttle/block Tor traffic based on that metadata [4] [6].
4. Practical Variations — NAT, CGNAT, Bridges, and ISP Policies
Logging details vary by provider and network architecture. ISPs using NAT or CGNAT typically log mappings that include the public IP and ephemeral source port assigned to a subscriber flow, meaning multiple customers may share the same public IP and be differentiated only by source ports and internal logs. Using a Tor bridge can hide the fact that you connect to a known public Tor guard, because bridges are less easily enumerated; ISPs will still log the outer connection to the bridge’s IP, but not that it is an official guard, and some recommend bridges to reduce flagging or blocking by ISPs [2] [6].
5. Competing Perspectives, Limitations, and What is Omitted from Common Discussions
Community Q&A and guides converge on the basic technical facts but diverge on emphasis and mitigation. Some sources stress that Tor plus HTTPS protects content from exit nodes but note exit nodes can see plaintext to destinations without TLS; other discussions emphasize using bridges or VPNs to hide Tor use from an ISP. What is often omitted in short answers is the legal and operational context: retention policies, subpoena processes, and ISP‑specific logging configurations differ by jurisdiction and provider, so the exact retention duration and accessibility of those timestamps and IP logs depend on local law and ISP policy — details not captured in the technical Q&A summaries [7] [8].
6. Bottom Line for Users Who Care About Logs and Exposure
If your concern is whether an ISP will have a record tying your account to Tor use, the answer is yes — ISPs log connection metadata that shows when and to which Tor entry you connected, including timestamps and assigned IP/port. If your concern is whether the ISP can see the sites you visit inside Tor, the answer is no — Tor’s encryption prevents ISPs from seeing inner circuit destinations or packet contents. Users who require additional obscurity should consider bridges, careful client configuration to avoid DNS leaks, and understanding provider retention and legal regimes because metadata retention and possible cross‑correlation remain the principal exposures documented in technical community analyses [2] [5] [4].