如何记录并核验你用过的 VPN 出口地址
客户端应用显示的是地点名称，而不是你的流量实际离开的地址。连接时记录出口 IP，并与直连基准对比。
问桌面 VPN 客户端用过哪些服务器，诚实的答案通常只是一个地点名称。那个名称是你选择接入的入口，而 你的流量实际离开的地址可能完全是另一台机器。应用里没有任何设计用来保留第二个数字，所以记录只能在使用当时建立。有两种做法，其中只有一种能经受一次支持工单的考验。
两份记录，只有一份真实存在
客户端自己的视图充其量是一份带时间戳的地点清单。这是设计取舍而不是疏忽：地址属于运营细节，它们会在分配之间轮换，而公开映射会让支持和滥用处理都更难。服务商把云实例放在网络前端，正是为了让出口端点能在不通知任何人的情况下迁移。应用展示给你的是你做出的选择，而不是流量走过的路由。
你能建立的那份记录，是一个本地文件，每行一个公网地址和一个 UTC 时间戳。它更小、更丑，也远更有用，因为它描述的正是外部观察者同样能看到的东西。
方案 A：自己记录出口地址
回声服务会返回请求的来源地址，按定义那就是出口地址。要在隧道报告连接之后再执行记录，因为一个在路由和 DNS 稳定前就显示已连接的客户端，会把隧道前的地址写进日志，从第一行起就污染整份记录。
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"两个细节让这段脚本可用而不只是装饰。时间戳和地址占同一行，之后的解析不必再配对记录；umask 077 从文件创建那一刻起就保持私有。每次连接运行一次，而不是每次开机运行一次，并且每台设备保留一个文件。
日志记下你何时使用了隧道、从哪个网络出现，这比计数器更接近浏览历史。选择一个你能为之辩护的保留期，把文件放在共享同步文件夹之外，并有意识地清理它。
方案 B：向服务商索取历史
有些服务商保留连接日志，会用时间戳和服务器名称回答支持问题。那份记录描述的是他们的基础设施而不是你的流量，它的价值仅取决于他们的保留窗口和查看意愿。它描述的也是一次会话，而不是某个具体请求。窗口通常很短，而且是从隧道服务商一侧计算的。
宣称不保留日志的服务商无法按要求提供这些，而客户端侧的最近地点列表并不是同一回事。向无日志服务商索要出口地址，通常以解释这些数据为何不存在收场。
在支持工单里，每份记录能证明什么
两份记录回答的是不同的问题，而对比真正落地的地方是那张表。
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
只有第一列在你手中。服务商记录可以确认某个账号在某一时刻处于连接状态，却无法确认哪些请求走了隧道，也不会给出一个被他们视为运营细节的地址。两份记录都指认不了某个人，因为一个共享出口地址在同一分钟里可能承载许多客户。
信任任何一份之前，先把两者都与基准对比
单看地址什么也证明不了。连接前记录直连地址，连接后记录隧道地址，再作对比。数值相同意味着隧道没有承载那次请求，原因可能是分流隧道、优先代理，或者客户端回落到直连路径。
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1DNS 和 IPv6 也要重复这项对比，因为地址回声只证明一次 HTTP 请求的路径，说明不了是哪个解析器作了回答。一个在这两项中泄漏的设备，在另一项上可能看起来完全健康。