1) DNS 泄漏 / DNS 污染（概念、危害、检测与修复）

什么是 DNS 泄漏 / DNS 污染（通俗）

• DNS 泄漏：你本来应该通过「某个安全通道（比如 VPN / 代理的 DNS）」去解析域名，但实际上系统/应用把 DNS 请求发给了其它 DNS（比如 ISP 的 DNS）——这会暴露你访问的域名给第三方。Tom’s Guide
• DNS 污染（DNS 劫持/中毒）：攻击者或 ISP 修改 DNS 响应，把域名解析到错误的（有害或被监控的）IP。可以导致无法访问、被钓鱼或被劫持。NIST 对 DNS 攻击与缓解有系统性说明。NIST 技术系列出版物

如何检测（简单到进阶）

1. 最简单的网页检测：访问 dnsleaktest、ipleak、whoer 等在线检测（可显示解析服务器）。（这类工具能快速给你提示谁在解析你的域名）Whonix
2. 命令行（更可靠）：
   • 查看当前 resolver：nslookup www.google.com 或 dig +short @resolver1.opendns.com whoami.opendns.com（看返回的 DNS 服务器）
   • 抓包观察（最可靠）：用 tcpdump -n -i <iface> port 53 或用 Wireshark 过滤 dns，看 DNS 请求的目的 IP / 协议。nsrc.org
3. 针对 DoH/DoT 等加密 DNS，抓包需要看目标 IP/端口（DoH 多跑 443，但可看域名 SNI/请求目的地 IP）。

常见原因（为什么会发生）

• 客户端或系统没有把 DNS 设置到 VPN/代理提供的 DNS（配置不全或客户端 bug）。Mullvad VPN
• 操作系统（尤其 Windows）有“优先使用本地 DNS”或 IPv6/DNS 缓存导致的回退。
• 本地路由器或 ISP 强制拦截/劫持 DNS（把 53 端口劫持到自家解析器）。Cloudflare Community

修复与防护（逐步，实操）
A. 最简单且常见的修复

1. 在 VPN/代理客户端里启用“防 DNS 泄漏”或“使用远程 DNS”选项（很多成熟客户端有一键设置）。Mullvad VPN
2. 把系统 DNS 指向可信的加密 DNS（例如 Cloudflare 1.1.1.1、Google 8.8.8.8，但最好使用 DoH/DoT 客户端）并在客户端启用 DoH/DoT。
3. 若路由器劫持 53 端口，可以在本地设备上把 DNS 发到 DoH 端点（cloudflared 或 systemd-resolved 的 DoH）。

B. 强硬办法（对付 ISP 强拦截）

1. 强制走隧道的 DNS：在软路由/防火墙上加一条规则 —— 把所有 53/UDP, 53/TCP 的出站请求重定向到内网 DNS（或直接拒绝），强迫客户端使用你指定的 DNS。
2. 在 VPN/软路由上启用 DoH/DoT 中继（如 cloudflared、dnscrypt-proxy 或 dnsmasq + DoT）来加密 DNS。Control D+1

C. 防御性策略（建议长期采用）

• 启用 DNSSEC（可防止缓存中毒，虽然并不能防止所有类型的劫持）。NIST 技术系列出版物
• 在关键终端上运行本地 DNS 缓存（dnsmasq / Unbound），再把它上游指向 DoH/DoT。
• 定期检查（自动化）：定时跑 dnsleak 测试，并记录解析 IP 的变化（异常报警）。

快速操作清单（复制粘贴可执行）

• 在 Linux 上查看 DNS：resolvectl status 或 cat /etc/resolv.conf
• 简单抓包看 DNS：sudo tcpdump -n -i eth0 port 53
• DoH 客户端示例：安装并运行 cloudflared proxy-dns --port 5053 --upstream https://1.1.1.1/dns-query，然后把系统 DNS 指到 127.0.0.1:5053。Mullvad VPN

2) 延迟 / 丢包 / 带宽瓶颈 —— 如何系统地诊断与提升

先理清要测的对象（诊断顺序）

1. 终端 → 本地网络（Wi-Fi / 交换机 / 网线）
2. 本地网络 → 路由器 / 家庭网关
3. 路由器 / 家庭网关 → ISP（到你的出网网关）
4. ISP → 目标服务器 / 代理节点（中间 Internet 路径）
5. 目标服务器自身（CPU、带宽限速、并发限制）

常用工具（入门 + 说明）

• ping：测延迟与简单丢包（只测 ICMP）。
• traceroute / tracert：看路径跳数与哪个跃点延迟高/丢包。
• mtr（推荐）：把 ping 与 traceroute 结合，能实时看到每跳的延迟与丢包率。强烈推荐做端到端追踪。ServerSP
• iperf3：测真实吞吐（客户端 ↔ 服务器），测一个链路的最大带宽/抖动。Kerry Cordero
• tcpdump / Wireshark：抓包看 TCP 重传、握手延迟、MTU 问题等。nsrc.org

诊断步骤（实用、按步骤）

1. 本地基础检查
   • 换线/换口/换网卡/换 Wi-Fi 到有线，确认是否是物理层问题（断线、干扰）。
   • 在同一 LAN 内做局域网 iperf3 测试（比如把一台机器当服务端 iperf3 -s，另一台跑 iperf3 -c server），看本地吞吐是否正常。
2. 到网关 / ISP 的检查
   • 用 mtr your.node.ip（或 mtr -r -c 100 <node>）跑一段时间，注意哪一跳开始出现丢包或高延迟；如果丢包发生在 ISP 节点，问题通常在 ISP 链路。ServerSP
3. 到目标代理/节点 的功能检查
   • 在节点上跑 iperf3（若可控），测试到节点的吞吐；若节点端带宽本身受限，客户端再怎么优化也没用。
4. 协议层面问题
   • 看 TCP 重传/握手超时：用 Wireshark 或 tcpdump 看是否有大量 TCP 重传（可能是 MTU 不匹配或中间设备丢包）。nsrc.org

常见原因 & 对应优化方法（按因对策）

• 高延迟：通常是地理距离或者 BGP 路由差导致。
  对策：选择地理更近或路由更优的节点；尝试使用中继（中转）到网络质量更好的中转机房；优先选择低跳数/低延迟的机房。
• 丢包：可能是链路拥塞、交换机/路由器丢包或 ISP 接口错误。
  对策：先定位在哪一跳丢包；若是家庭网侧，可更换交换机/网线；若是 ISP 侧，可与 ISP 报障并给出 mtr 报告。NetBeez
• 带宽瓶颈：本地设备或节点限速。
  对策：用 iperf3 测试端到端吞吐，排除谁在限速；确认是否为 TCP 窗口/拥塞控制问题（开启 BBR 可提升高带宽高延迟链路的吞吐）。
• MTU/分片问题：若通过某些隧道（例如 GRE、IPsec），可能导致分片与重传。
  对策：用 ping 的 -M do -s <size> 检测最大不分片 MTU，然后把隧道/接口 MTU 调小。
• 协议和实现选择：
  • WireGuard / QUIC（基于 UDP） 通常比 OpenVPN/TCP-over-TLS 更低延迟、更高吞吐且复原性好。建议优先用 WireGuard（或基于 QUIC 的实现）测试性能改善。goodaccess.com+1
  • 使用基于 TCP 的代理（如某些 websocket + TLS 实现）在丢包或高延迟网络上表现差，UDP/QUIC 更强健。
• 节点负载高：很多公共节点在高峰期被 saturated（CPU 或带宽耗尽）。
  对策：监测节点的 CPU/网口利用率，选择负载低或带宽更大的节点。

性能优化实务清单（可直接照做）

• 先做 mtr -r -c 100 <node_ip>，把输出保存为文本（便于向服务商/机房报障）。ServerSP
• 在可控节点上跑 iperf3 -s，在本地跑 iperf3 -c <node_ip> -P 10 看并发吞吐能力（-P 10 表示 10 路并发）。Kerry Cordero
• 若确认链路瓶颈在 TCP 拥塞：在 Linux 服务器启用 BBR：sysctl -w net.ipv4.tcp_congestion_control=bbr。（注意：需要内核支持）
• 优先测试并考虑 WireGuard / QUIC 等现代协议替代旧的 TCP-over-TLS 隧道（会有明显延迟/吞吐改善）。CyberInsider+1

3) 节点订阅 / 转换服务的高危漏洞

先说明“节点订阅 / 转换服务”是什么

• 很多代理服务把一串节点信息（IP、端口、加密方式、密码、认证 token）打包成订阅链接（通常是 base64 或 json 的一段字符串），客户端订阅后自动获取多个节点配置。第三方“订阅转换器/聚合器”可以把不同格式互转（例如把 ss/vmess/tron 导出成 clash 订阅）。
• 风险点：这些订阅里常包含真实节点 IP、端口、用户名/密码或 token —— 一旦第三方服务、转换器或传输链路被记录，就会泄露这些信息。泄露后，别人可以直接使用你的节点、扫描攻击、滥用带宽，甚至发现你在使用/管理这些节点。

高危场景举例（会发生什么）

1. 你把订阅链路发到第三方转换网站 → 网站保存了订阅信息 → 别人抓取或站点被攻破，节点被批量滥用或攻击。
2. 公开仓库/论坛粘贴订阅（未加密）→ 搜索引擎或爬虫收录 → 节点暴露。
3. 使用免费/不可信转换器/APP → App/服务器在后台收集并上传你的 subscription，开发者或第三方拿去分析或售卖。
   （这些都会导致节点被封、IP 被打击、带宽被盗用，甚至暴露你活动线索。）

技术细节（你应该知道但不必记全）

• 订阅字符串里常见敏感字段：server（IP）、port、uuid/password/token、path（有时包含关键参数）。很多客户端只是 base64 解码就能看到明文配置信息。
• 转换服务如果不使用 HTTPS 或在服务器端日志保留明文，就会在传输或日志里被记录。

逐条防护与操作指南（实操、详尽）
A. 不要把订阅公开或交给不可信服务

• 切记：任何公开贴出的订阅链接都等同于把节点钥匙交给了全世界。不要在论坛/GitHub/Gist/公开云盘/聊天群里贴原始订阅。

B. 给每个用户 / 客户端分配独立凭证（最重要）

• 不同用户用不同的用户名/密码或 UUID，便于发现异常（某个凭证被滥用就停掉它）。这是一条基本但常被忽视的安全措施。

C. 短期 / 轮换凭证 + 最小权限

• 使用短期 token（例如只允许使用 7 天）或定期轮换密码。若节点提供 API，限制 token 的权限与来源 IP。

D. 自建订阅 / 转换服务（优选）

• 如果你有能力，自建一个订阅服务（只允许内部或使用 HTTPS、加密存储，不把明文写入日志），不要使用未知第三方在线转换器。
• 若不得不用第三方，先审查其隐私政策与源代码（开源更好）。
  （注意：自建时确保 web 服务没有写入明文日志。）

E. 传输安全（HTTPS/TLS）与客户端校验

• 订阅链接必须用 HTTPS。服务端启用 HSTS、TLS 强加密。
• 在服务端做访问频率限制（Rate Limit），防止批量抓取。

F. 对付“订阅泄露后被滥用”

• 给节点做 访问 ACL（白名单），仅允许特定国家/IP 段或登陆认证后的流量。
• 使用 CDN/反向代理隐藏真实节点 IP：把域名用在订阅里，背后再做负载均衡或流量代理（这能减少直接对真实节点 IP 的扫描与攻击）。Cloudflare 等能在一定程度上保护真实源 IP，但配置不当仍会泄露。Cloudflare Community

G. 监控与告警（务必有）

• 在节点端启用访问日志与异常告警：当单个节点短时间内爆发高并发/带宽时，自动触发告警并临时封禁疑似被盗的凭证。
• 定期比对订阅的 IP 与机房暴露日志（若发现某凭证被他人使用，立即轮换）。