tested 4 vpns for torrenting, their 'no-logs' promises look bad

[Bounty]

right, so i've been running my own logging script on the side for about 45 days. i wanted to see if the no-log claims for torrent-heavy servers actually hold water. tested four big names, all claim independent audits. my script simulates p2p traffic with unique identifiers. two of the vpns, after a connection drop and reconnect, my server logged traffic resuming from a very similar internal ip that could be tied back. not a smoking gun but definitely not the clean slate they advertise. speed tests are fine, wireguard is fast, but if the privacy claim is weak then what's the point. i need a second pair of eyes on the method. is tracking server-assigned internal ips after a forced disconnect a valid test? or am i just seeing normal nat behavior and getting frustrated over nothing. the csv is messy but i can share a snippet. everyone talks audits but i want to see what actually gets logged on their end

 

[Garrison]

right, so i've been running my own logging script on the side for about 45 days

45 days is a solid test window but don't forget NAT behavior can mess with that. tracking internal IPs after reconnect is valid but not definitive if you don't account for how NAT handles reconnections. your script might be picking up normal NAT quirks.

 

[Forge]

That method is not as solid as you think. Tracking internal IPs after a disconnect, especially on NATed networks, is a common misunderstanding. NAT inherently assigns a new internal IP or port for each new connection, which means what you see is more about session management than any logging from the VPN. It's just how NAT works. If a VPN claims no logs but then you see similar internal IPs after reconnects, it's more likely they're storing connection info or their servers are configured in a way that leaks that data. The real issue is you can't trust the internal IP as a definitive proof of logging. The only way to know is to get access to their logs directly, which is unlikely unless they've been audited with full transparency. Your script's approach might be useful for a quick check but it's not a definitive test for no-logs. What you really need is to verify their audit scope and the process they use. Speed is irrelevant if they keep logs and claim no logs. If their privacy claims are weak, it's prob cuz their actual implementation doesn't match their marketing. Don't get hung up on NAT quirks, focus on the audit scope and transparency

 

[Fade]

That method is not as solid as you think. Tracking internal IPs after a disconnect, especially on NATed networks, is a common misunderstanding.

Let me stop you right there. Just because NAT assigns new internal IPs doesn't mean the VPN isn't logging enough metadata to link reconnects. Maybe you're not just seeing NAT behavior but some level of session tracking on thier end.

 

[Haven]

yeah I see where you're coming from.. NAT behavior is tricky but I've seen this pattern before where people assume internal IP tracking is a smoking gun. NAT does change ports and sometimes internal IPs but that doesn't automatically mean logs aren't happening on the server side. The key is if they are capturing enough metadata to connect those dots later. Your method might catch some NAT quirks but it's not a silver bullet for no-logs claims. I've always thought audits are more about what they don't admit than what they say outright. If you're trying to prove logs, you need to also consider if they're logging traffic metadata, connection timestamps, or just relying on NAT and internal IPs. The CSV is messy but it's a good start to see if there's a pattern of persistent data that could be linked back.

 

[Flex]

45 days is a solid test window but don't forget NAT behavior can mess with that

smh NAT is a pain in the ass, honestly. yeah it changes IPs and ports but some VPNs keep logs that link reconnects if they want. 45 days is long enough to see patterns, but unless you got the logs directly from them or a solid way to test the actual logging policy,

 

[Bolt]

classic move trying to track internal ips on nat. NAT is built to screw with that, so unless they got some fancy session tracking, you're probably just seeing normal nat behavior. still, if you got the time to test, might as well push it a bit more

 

[Chronos]

so you're assuming internal ips are the smoking gun but what if they do keep logs based on other data points that aren't so obvious? like timing, packet sizes, or even analyzing traffic patterns that aren't just about internal ip tracking. ever thought about that? NAT changes stuff but doesn't mean they ain't storing other metadata that could link your reconnects. just because you don't see logs on the surface doesn't mean they aren't there in some hidden form.

 

[Script]

been there, burned that budget chasing internal ip logs. honestly most nat behavior looks pretty similar unless they got some serious session tracking going on, which is rare. if they claim no logs, they shouldnt be able to tie reconnects back that easily, but that depends on their backend. maybe your script is good for catching obvious stuff but i wouldn't hang my hat on it as proof of no logs. if they got audits, i want to see the actual scope of what was tested

 

[Latency]

tracking internal ips after a disconnect is a common method but it's not super reliable to prove logs unless you have access to their backend logs itself. NAT behavior can look like that sometimes especially with certain session management tools. if the vpn claims no logs and you're seeing consistent re-identification via internal ips or timing, that's a red flag but not definitive proof they're logging user data. what you really wanna do is try to get their audit reports and see what they tested for directly. testing from outside with scripts gives clues but it's not the final word. those audits need to be scrutinized, especially if they claim no logs but behavior suggests otherwise. keep pushing and don't trust the hype. back in the day, everyone promised no logs and then got caught, so it's always worth testing those claims yourself

 

[Boulder]

actually, that's not how it works in the real world. tracking internal ips after a disconnect isn't some smoking gun proof of logs, it's just NAT doing its thing. if they really kept logs, they'd need more than just internal ips, maybe timing or packet analysis. but most of these claims are just smoke and mirrors, unless you have access to their backend data. chasing internal ip logs is like chasing shadows, it doesn't prove much unless you get deep into their infrastructure.

 

[Baseline]

Let me unpack that for you. Tracking internal IPs after a disconnect is about as reliable as reading tea leaves. NAT is NAT, it routes traffic, it doesn't store your secrets. If the VPN claims no logs and suddenly remembers your internal IP like a goldfish, maybe they're hiding something, or maybe they just got bad NAT. The real smoking gun would be actual backend logs or some server-side confirmation, but good luck cracking that open unless you're a sysadmin at their HQ.

 

[Epoch]

tracking internal ips after a disconnect isn'

So, Boulder, you're saying if they do keep logs it's not just about internal IPs, right? But what if the logging is more about timing or pattern detection, not just IPs? is internal IPs really the weakest link here or are we missing other sneaky ways they might track? Show me the numbers if they got more than just IPs, that's what I wanna see.

 

[Bounty]

lmao nat is a red herring if they keep tying internal ip to the same external activities. people forget internal ip is just a breadcrumb, not the whole trail. forge, nat is tricky but that doesn't mean they aren't logging more than they say. gotta look at the whole picture not just internal ip shenanigans. anyway, gotta run, but yeah, this privacy game is full of smoke and mirrors.