隐藏源站 IP：一套真正扛得住的离岸反向代理方案

隐藏源站，究竟换来了什么

三件事，而且值得说得精确一些。第一，洪流不再涌向那台扛不住它的机器：单台 VPS 的上行带宽终归有限，当吞下数据包的地址是一个专门为此而生的边缘节点，而不是那台装着你数据库的机器时，一次流量型攻击就变成了别人的工程问题。第二，应用不再能被绕开自身防线直接访问到——速率限制、机器人规则、WAF 与地理封锁，对任何能直连源站的人来说都形同虚设，而大多数部署了这些措施的人，从未去检验这一点是否依然成立。第三，提供内容的那个地址，不再是存放你数据的那个地址，正是这层分离，才能让一次滥用投诉、一次扫描或一次针对性探测，落在一台廉价且可随时更换的机器上。

接下来是诚实的另一半。隐藏源站不等于匿名——它藏起来的是一个地址，而不是一个人，而付款痕迹、域名注册信息，以及它们背后的账户，是另一个需要单独解决的问题，另有一篇指南专门讲这个。它也不能修补你的应用：一个没人能找到的源站，一旦被人找到，依然可以被利用，而源站确实会被找到。它更不能对你的服务商隐藏任何东西——服务商按定义就知道哪台机器在哪个地址上应答。把它当作一层能提高攻击成本的防护，架在一台已经先做好加固的机器之上——而不是替代这两者中的任何一个。

源站 IP 泄露的所有途径

很多所谓已经隐藏好的源站，之所以其实并没有真正藏住，是因为人们关掉了一个渠道，就以为其余渠道也跟着一起关掉了。事实并非如此。以下是我们会逐一排查的清单，大致按它们真正坑过人的频率排序：

• 历史 DNS 记录。早在你搬到代理后面之前，被动 DNS 收集器就已经在记录你的 A 记录。你去年用过的那个地址，如今是一条永久保存、可搜索、免费查询的记录。
• 证书透明度。每一张受公开信任的证书，都会被发布到仅追加的公开日志中，其中涵盖它所覆盖的每一个主机名。为 origin.example.com 签发的证书，会把这个名字公之于众，剩下的事交给它的 A 记录就够了。
• 从未迁移过的子域名。mail、ftp、webmail、cpanel、dev、staging、vpn、monitor——顶级域名搬到了 CDN 后面，这些子域名却还留在原地，指向那台机器。
• 邮件。源站上的 MX 记录会直接暴露地址；你的应用发出的邮件里的 Received: 头同样会暴露地址，而任何人都能靠一个密码重置表单触发这封邮件。
• 出站请求。Webhook、头像抓取、RSS 拉取、链接预览、更新检查、OAuth 回调。每一个都会把源站的地址暴露给对面服务的运营者——而一个链接预览功能，则让攻击者自己选择那个对面服务是谁。
• 裸地址上的应答。如果源站在收到一个 Host 头对不上的请求时，仍然把你的网站内容返回回去，那么全网扫描器早就已经把它收录了：favicon 哈希、页面标题、证书指纹和 HTTP 头顺序，全都是可以搜索到的。
• 被你忘掉的 IPv6 记录。A 记录搬到了代理上；AAAA 记录却仍然指向家里。
• 应用自己说漏了嘴。CMS 配置里的绝对路径 URL、指向内部主机名的重定向、堆栈跟踪、Server 响应头、source map 文件、一个无需身份验证的状态接口。

请注意，这些渠道里的大多数都有一个共同点：它们是永久性的。证书日志仅追加，被动 DNS 则是一份存档。地址一旦公开，就无法撤回——你只能停止使用它，这正是下文操作顺序如此重要的原因。

两种边缘节点：一层 CDN，或者一台你自己的机器

商业 CDN 能给你任何单台服务器都比不上的任播容量，覆盖几十座城市，往往还有免费档位可用。代价是 TLS 在你无法掌控的基础设施上终止：运营商能看到你的明文流量，知道它属于哪个账户，既可能被要求依据这份认知采取行动，也可能某天早上突然自行决定你的内容不受欢迎。共享前端还有一个更隐蔽的问题——如果你的源站防火墙放行了 CDN 公布的地址段，那么任何在那家 CDN 上开了账户的人都等于站在了你的白名单之内，能把自己的主机名指向你的源站。这是一种真实存在的绕过手段，不是纸上谈兵，这也正是鉴权回源机制存在的原因。

自己运行的边缘节点，付出的是相反的代价。除你之外没有人握有私钥，这台机器所在的司法管辖区是你自己刻意选定的，最小套餐每月只要 $8.00——相对于它所保护的东西，这点花费实在算不上什么。你得不到的是任播能力：不管你的 nginx 配置写得多精巧，一次 200 Gbps 的洪流都会灌满这个边缘节点的上行带宽，所以网络层面的吸收终究得有人来扛。在我们这里，扛住这件事的，是部署在机群中每一台机器前端、1.5 Tbps 的上游清洗，这才是让自建边缘节点真正可行、而不是沦为单点故障的原因。这两种形态也可以叠加使用：前面用 CDN 负责触达面和流量规模，后面用你自己的节点守住你拒绝交出去的那部分。该怎么选，取决于你更愿意向谁解释哪一种失败。

隧道，是大多数人搭错的那一环

常见做法是让源站监听在 0.0.0.0:443 上，再用防火墙给代理的地址开白名单。这样做能用，却是整个设计里最脆弱的一环。白名单会漂移——公布的地址段发生变化，而更新却从没被应用上；它是共享的，所以在一个公共 CDN 上，它等于向对方的每一个其他客户都敞开了大门；而且它在真正要紧的方向上是失效开放的，因为源站始终是一个活着的公网监听端口，只等着一次配置失误，或者调试过程中一次 ufw disable。

真正扛得住的版本反其道而行之：源站完全没有公网监听端口。在边缘节点与源站之间建立一条 WireGuard 隧道，Web 服务器只绑定隧道地址，公网接口在两个 IP 协议族上都执行默认拒绝策略，80 和 443 也不例外。这样一来，可达性就不再是一条谁都可能忘记续期的规则——而是彻底没有路由。WireGuard 在这里是正确的工具，因为它是一个攻击面极小的内核模块，对未经身份验证的扫描器保持沉默（一个未经认证的数据包得不到任何回应，所以那个 UDP 端口看起来根本就不存在），而且每个数据包的开销只有个位数微秒。如果你以前没搭建过，WireGuard 指南讲解了基础知识；这里我们只需要一条双节点的点对点链路。

动手之前有一条规矩，正是它能让你保住一个下午的时间：全程保持第二个 SSH 会话连接不断。把 SSH 锁在一条你还在重新配置的隧道后面，正是人们弄丢一台机器的经典方式，而在一台没有任何身份登记在案的主机上，既没有客服阶梯可爬，也没有人能给你开一个控制台会话——回去的唯一办法，是重新部署加恢复，如果你的备份是最新的，这个过程会很快；如果不是，那就是永久性的。

证书，以及那份公开你主机名的日志

证书透明度确实是件好事，但它也很乐意毁掉你一整周的心情。每一张公共 CA 签发的证书，都会被提交到任何人都能搜索的仅追加日志中，其中的条目包含证书里的每一个名字。为 origin.example.com 或 direct.example.com 签发一张证书，就等于把你原本不想暴露的那个主机名，永久地、以结构化的格式公之于众。更糟的是，把预发布环境和管理后台的主机名，习惯性地塞进同一份 SAN 列表，会让一次疏忽的续期，变成一张你整个基础设施的地图。

正确的做法很简单。公共证书只放在边缘节点上，且只覆盖公众实际会用到的那些名字。源站则使用自签名证书，或者来自一个小型私有 CA 的证书，并通过 proxy_ssl_trusted_certificate 固定在代理配置里——一条只有你自己的代理会去访问的链路，不需要任何东西是公开可信的，为它签发一张公共证书除了在日志里留下一条记录之外什么也换不来。如果你需要很多个公开子域名，一张通配符证书能只公开一个名字，而不是三十个。再把 ACME 切换到 DNS-01 验证：HTTP-01 需要有某个东西在 80 端口上为待验证的主机名作答，而这恰恰就是你刚刚撤掉的那个公网监听端口。最后，要接受这种不对称——日志是仅追加的，所以一个你已经公开过的主机名，无法再被撤回。如果它曾经解析到源站，那么源站需要换一个新地址。

邮件，以及那些在错误地址上应答的其他服务

邮件是最经典的绕过途径，因为按定义它就必须是可达的。如果你域名的 MX 记录指向源站，那么这场游戏还没开始就已经结束——这条记录是公开的，一次 dig 查询就能终结这场搜寻。就算 MX 指向了别处，一个直接从源站发信的应用，也会把发信主机的地址打进每一封邮件的 Received: 链条里，而任何一个能按需给用户发信的表单，都会把这变成一次自助式查询。修复方法是让源站只做客户端，绝不做服务端：把出站邮件中继到一个投递服务或另一台单独的机器上，把 MX 留在一台允许被找到的机器上，并在收工之前读一遍测试邮件的完整头信息。大规模自建邮件系统本身就是一个独立项目，不该放在你正要隐藏的这台机器上。

接下来，要地毯式排查其他一切正在悄悄监听的东西。监控代理、容器管理面板、"临时"打开的数据库端口、9100 端口上的指标接口、跑在高位端口上的控制面板、公网接口上的 SSH 守护进程。它们每一个，都是在你试图保密的那个地址上应答的服务，而扫描器找高位端口和找低位端口一样轻松。审计只需要一条命令——ss -tulpn——正确的输出应该是一份没有任何东西绑定在公网地址上的清单。下面的第三步，就是让这一点成立、并持续成立的关键。

出站流量：源站主动发起的连接

一个什么都不接受连接的源站，依然可能出卖自己，因为它不只是接收连接——它也会主动发起连接。软件包镜像源、NTP、发给支付处理商的 Webhook、某个机器人 API、为生成链接预览而抓取的图片、许可证校验、一次出站 SMTP 会话、一个 Git 远程仓库、一个错误上报服务。对这些连接对端而言，源站的公网地址不过就是这次连接的来源地址。多数情况下这无伤大雅，因为对端是你自己选的，你也信任它。真正的问题在于那一小撮由攻击者来挑选的端点：只要把一个链接粘贴进任何会渲染预览的功能里、注册一个 Webhook，或者在某个图片导入器里找到一个服务端请求伪造漏洞，源站就会去解析并连接到攻击者正在盯着的那台主机。这是一次两分钟就能完成的去匿名化，甚至用不上什么漏洞利用。

有两种站得住脚的应对方式。严格的一种，是把全部出站流量都经隧道路由，交给边缘节点做 NAT，这样源站出站连接的源地址就变成了边缘节点的地址——对端配置里的一个设置项，加上转发规则和另一端的一条伪装规则即可。wg-quick 会替你处理好路由回环问题：配上一条 0.0.0.0/0 路由后，它会安装一条 fwmark 规则，确保隧道自身的数据包依然能直连端点，而这正是人们手写路由时最容易搞砸的部分。务实的一种做法，是对你自己掌控的流量保留直接出站，再给任何会抓取用户提供的 URL 的功能前置一个代理。真正站不住脚的，是根本不知道自己属于这两种里的哪一种。要主动地做出选择，然后用一次发往你自己所有的主机的请求，并查看其日志里的来源地址，来验证它。

成本几何，以及如何证明它确实有效

预算上多出来的，就是一台额外的 VPS。$8.00/月起的最小套餐，就足以为一个小型网站终止 TLS 并做反向代理，完全感觉不到负载——反向代理干的主要就是复制套接字数据，2 vCPU 配 4 GB 内存，游刃有余，远远超过它背后的源站先成为瓶颈的那个临界点。把它放在和源站不同的地区，这样一份法律文书或者一次机房事故就不会同时殃及两边；同时别忘了延迟：多一跳会实实在在地增加毫秒级延迟，所以把边缘节点放在阿姆斯特丹、源站放在吉隆坡，这该是一个刻意的设计决定，而不是无心插柳。位于同一大洲的组合，通常只会多出个位数毫秒，而你在边缘节点获得的 TLS 会话复用，往往能在实际页面加载中把这点延迟赚回来。

证明它确实有效，是把一份配置和一项管控真正区分开来的地方，而且这是一项需要反复去做的工作，不是一次性的——每一个新增子域名、每一张新证书、每一次新的第三方集成，都是重新公开这个地址的一次新机会。第七步里的这一整套检查大约要花十分钟：尝试直接用源站地址访问你的网站、列出你曾经申请过证书的每一个主机名、逐一试探那些显而易见的子域名、检查你忘掉的 AAAA 记录，并给自己发一封邮件。每一次基础设施变更之后都要跑一遍。做的时候要记住这个结论：如果源站真的应答了，正确的修复方式不是再加一条防火墙规则——而是换一个新地址，因为旧地址早就已经躺在某人的存档里了。在整套体系中，这一层位于加固之后，并与异地备份并列：加固决定这台机器有多难被攻破，备份决定你恢复的速度有多快，而这一层决定的，是这台机器起初到底有多难被找到。

分步操作

1. 01

   部署边缘节点，只交给它一项任务

   在一个不是源站所在的地区部署第二台 VPS，把它当成一台单一用途的专用设备来对待：TLS 终止、反向代理，仅此而已。没有数据库，没有应用代码，也没有任何一个会被人惦记的 shell 脚本。在它上面跑一遍第一小时清单——仅密钥 SSH、两个 IP 协议族都默认拒绝的防火墙、无人值守的安全更新——然后精确开放三个端口。

   ssh root@198.51.100.20
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y nginx wireguard-tools ufw unattended-upgrades
   
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp
   ufw allow 80,443/tcp
   ufw allow 51820/udp
   ufw --force enable

2. 02

   动 DNS 之前，先把隧道打通

   两个节点，一条链路。分别在两台机器上生成一对密钥，并给这条隧道分配一个属于它自己的小子网——最终源站将只在 10.66.0.2 这一个地址上可达，别无他处。由源站主动拨号连向边缘节点（因为源站这一侧到时候不会开放任何端口），所以配置里带 Endpoint 和一个 keepalive；边缘节点这一侧则只负责监听。

   # on both machines
   umask 077; wg genkey | tee privkey | wg pubkey > pubkey
   
   # edge-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.1/24
   ListenPort = 51820
   PrivateKey = <edge-privkey>
   
   [Peer]
   PublicKey = <origin-pubkey>
   AllowedIPs = 10.66.0.2/32
   
   # origin-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.2/24
   PrivateKey = <origin-privkey>
   
   [Peer]
   PublicKey = <edge-pubkey>
   Endpoint = 198.51.100.20:51820
   AllowedIPs = 10.66.0.1/32
   PersistentKeepalive = 25

   在两端都启用它，并在继续下一步之前先确认握手成功——一条只撑到下次重启就失效的隧道，比根本没有隧道更糟。

   systemctl enable --now wg-quick@wg0
   wg show          # expect a recent handshake and non-zero transfer
   ping -c3 10.66.0.1   # from the origin

3. 03

   让源站从公网彻底不可达

   这一步才是真正干活的地方，也是人们最容易把自己锁在外面的一步。打开第二个 SSH 会话，并且在执行下面任何命令之前，先让它保持连接——这里没有支持控制台能兜底。接着把 Web 服务器绑定到隧道地址上，丢弃公网接口上的一切流量，只放行隧道本身以及 WireGuard 端点。

   # /etc/nginx/sites-available/app  — listen on the tunnel only
   listen 10.66.0.2:8080;
   
   ufw --force reset
   ufw default deny incoming
   ufw default allow outgoing
   ufw allow in on wg0 to any port 8080 proto tcp
   ufw allow in on wg0 to any port 22 proto tcp
   ufw allow from 198.51.100.20 to any port 51820 proto udp
   ufw --force enable
   
   # the audit: nothing may be bound to a public address
   ss -tulpn | grep -Ev '10\.66\.0\.2|127\.0\.0|\[::1\]'

   如果最后这条命令打印出了某个服务，那就是一处泄漏——去修正绑定地址，而不是围着它再加一条防火墙规则。允许留存的监听端口只有两个：51820 上的 WireGuard，以及尚未迁移到隧道上的 sshd（如果你还没做这一步的话）。

4. 04

   在边缘节点终止 TLS，经隧道反向代理

   在边缘节点上，为公众实际使用的那些名字签发公共证书，并反向代理到隧道地址。第二个 server 块不是可有可无的装饰：正是它阻止了边缘节点向那些不带 Host 头、直接用 IP 连接的扫描器提供你的网站内容——而这正是站点入口被做指纹识别的常见途径。

   # edge-01 — /etc/nginx/sites-available/example.com
   server {
       listen 443 ssl;
       http2 on;
       server_name example.com www.example.com;
   
       ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
       add_header Strict-Transport-Security "max-age=63072000" always;
   
       location / {
           proxy_pass http://10.66.0.2:8080;
           proxy_set_header Host              $host;
           proxy_set_header X-Real-IP         $remote_addr;
           proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_http_version 1.1;
       }
   }
   
   # anything that is not a known hostname gets nothing at all
   server {
       listen 80 default_server;
       listen 443 ssl default_server;
       ssl_reject_handshake on;
       return 444;
   }

5. 05

   把真实客户端 IP 还给源站

   在代理后面，每一个请求看起来都来自 10.66.0.1。如果放任不管，你的访问日志就会变得毫无意义，按 IP 做的速率限制限制的会是隧道本身而不是攻击者，而 fail2ban 最终会封禁边缘节点、把网站直接搞下线——这是在做加固的过程中，一种货真价实的、造成服务中断的常见方式。要信任转发头，但只信任来自隧道地址的那一份，绝不信任来自外部世界的。

   # origin-01 — /etc/nginx/conf.d/realip.conf
   set_real_ip_from 10.66.0.1;
   real_ip_header   X-Forwarded-For;
   real_ip_recursive off;

   在应用层面也要做等效处理——Flask 里的 ProxyFix、Laravel 里的 TRUSTED_PROXIES、加上 set_real_ip_from 以及框架自带的可信代理列表——并把速率限制放在边缘节点上，因为只有在那里，真实的客户端地址才是原生存在的：

   # edge-01 — /etc/nginx/nginx.conf (http block)
   limit_req_zone $binary_remote_addr zone=front:10m rate=20r/s;
   # then, inside the location block
   limit_req zone=front burst=40 nodelay;

6. 06

   把邮件和出站流量都搬离源站地址

   把 MX 记录指向一台允许被找到的机器，让出站邮件经由一个中继发送，而不是直接从源站发出，并把证书续期切换到 DNS-01 验证，这样就不需要任何东西在 80 端口上应答。接下来，再决定剩下的出站流量该怎么处理。如果要把全部出站流量都经边缘节点路由，就放宽源站的 AllowedIPs，让边缘节点做伪装（masquerade）——wg-quick 会自动安装那条让隧道本身保持可达的 fwmark 规则，所以你不需要为端点手写一条路由。

   # origin-01 — /etc/wireguard/wg0.conf, in [Peer]
   AllowedIPs = 0.0.0.0/0, ::/0
   
   # edge-01 — forward and NAT the tunnel
   echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-fwd.conf && sysctl --system
   ufw route allow in on wg0 out on eth0
   # in /etc/ufw/before.rules, above the *filter block:
   # *nat
   # :POSTROUTING ACCEPT [0:0]
   # -A POSTROUTING -s 10.66.0.0/24 -o eth0 -j MASQUERADE
   # COMMIT
   systemctl restart ufw && wg-quick down wg0 && wg-quick up wg0

   然后从源站这一侧验证一下：curl -s https://ifconfig.co 返回的必须是边缘节点的地址，而不是它自己的。

7. 07

   搜寻你自己的源站，然后写进运维手册

   像别人会做的那样去攻击它。第一条命令是最要紧的——如果直接寻址仍然能让源站把你的网站内容吐出来，说明上面的一切都还没起作用。

   # does the origin answer for your hostname?
   curl -sk --resolve example.com:443:203.0.113.10 https://example.com/ \
        -o /dev/null -w '%{http_code}\n'      # want: a timeout, not 200
   
   # every hostname you have ever certified, from the public logs
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | grep -o '"name_value":"[^"]*"' | sort -u
   
   # records that never moved
   dig +short example.com A; dig +short example.com AAAA; dig +short example.com MX
   for h in www mail ftp webmail cpanel dev staging vpn monitor origin direct; do
     printf '%-9s %s\n' "$h" "$(dig +short $h.example.com | tr '\n' ' ')"
   done

   然后从应用程序给自己发一封邮件，读一遍完整的 Received: 链条，再把一个你自己掌控的主机链接，粘贴进任何会渲染预览的功能里，看看是哪个地址抓取了它。把每一项检查正确的结果长什么样都写下来，并在每一次 DNS 变更、每一张新证书和每一次新的第三方集成之后，把整套检查重新跑一遍。只要其中任何一项暴露出了源站，就在一个全新地址上重建它——已经公开过的那个地址早就被存档了，任何防火墙规则都无法把它收回来。