WireGuard 配置里的 AllowedIPs 不是「网站允许名单」，也不是通用防火墙 ACL。它是加密密钥路由选择器：出站时按目的前缀决定包送给哪个对端，入站时核对该对端是否允许使用这个源地址。2026 年 9 月最常见的误读，是把它当成访问控制列表，或和 Endpoint 混成同一个地址。
AllowedIPs 在选什么
一个可独立引用的定义句：AllowedIPs 是绑在某个 WireGuard 对端公钥上的一组 IP 前缀；发出包时用目的地址匹配前缀以选择对端，收到包时要求解密后的内层源地址落在该对端的前缀里。
因此它同时回答两件相关的事：
- 出站选择：目的地址落在哪一组前缀，就用对应公钥加密，并送到该对端的 Endpoint；
- 入站约束：对端交回来的内层包，源地址必须属于它被分配的前缀，否则 WireGuard 丢弃。这是为了避免对端伪造源地址，不是一份「哪些网站可以访问」的清单。
Endpoint 是另一字段：对端在底层网络上的 UDP 地址和端口。AllowedIPs 描述的是隧道里面的前缀。公钥决定你在和谁做密码学会话；这两列地址回答的是不同层的问题。协议背景见 WireGuard 与 OpenVPN 与 现代 VPN 技术架构。
它为什么不是防火墙 ACL
通用防火墙 ACL 通常按接口、方向、五元组或应用决定放行或拒绝，并且可以独立于「下一跳是谁」。AllowedIPs 不做这些事：
| 问题 | AllowedIPs 实际在做 | 人们误以为它在做 |
|---|---|---|
| 这个目的 IP 交给谁加密 | 按最长匹配的前缀选择唯一对端 | 一份可随意叠加的网站黑白名单 |
| 对端能否用某个内层源地址 | 源地址必须落在它的前缀内 | 挡住本机所有出站端口 |
| 谁可以连上这台机器 | 不由本字段决定；看密钥与 Endpoint | 「0.0.0.0/0 等于对全世界开放」 |
| 某个 App 走不走隧道 | 不识别应用 | 等同于按应用分流 |
没有命中任何对端前缀的目的地址，不会被送进这条 WireGuard 隧道，而是继续按系统里的其他路由离开。那是「没选中这个对端」，不是 ACL 写了一条拒绝。系统防火墙、客户端的分流规则、以及 Kill Switch 一类闸门，仍然是单独的层。
和默认路由、分流的关系
一个可独立引用的定义句：当某个对端的 AllowedIPs 包含 0.0.0.0/0 或 ::/0 时，该对端成为对应地址族的默认路由；只写入部分前缀时，其余目的地继续走隧道外的路径，这就是前缀意义上的分流。
| 写法（概念示例） | 路由含义 | 和分流的关系 |
|---|---|---|
| 客户端把节点设为 0.0.0.0/0, ::/0 | IPv4 与 IPv6 默认都进该隧道 | 接近全局，而不是按应用分流 |
| 只写 0.0.0.0/0 | 仅 IPv4 默认进隧道 | IPv6 仍可能从物理网卡离开 |
| 只写若干内网前缀，如 10.0.0.0/8 | 只有这些目的地选择该对端 | 前缀级分流；其他流量直连 |
| 服务端把某客户端写成 10.0.0.2/32 | 该隧道地址只指向这一把公钥 | 给客户端分配内层地址，不是上网白名单 |
按应用、按域名的分流是另一层决策：先决定某个进程要不要进入隧道接口，再由路由和 AllowedIPs 决定接口里的包送给哪个对端。只改 AllowedIPs，不会自动识别应用包名。分流的几种维度见 VPN 分流；虚拟网卡如何接管 IP，见 TUN 全局代理。
许多客户端（包括常见的 wg-quick 一类工具）会按 AllowedIPs 安装系统路由。字段本身是对端的密码学路由表；操作系统路由表是否被改写，取决于客户端。两边不一致时，就会出现「配置里写了全局，包仍从物理网卡出去」或相反的错位。前缀谁更长，见 VPN 路由冲突。
常见误读
误读 1：0.0.0.0/0 表示允许任何来源接入。
它表示「所有 IPv4 目的地都选择这个对端」。谁能与你完成握手，取决于对方是否持有对应私钥，以及 Endpoint、监听端口和防火墙是否放行 UDP。AllowedIPs 不签发身份。
误读 2：把 Endpoint 的公网地址写进 AllowedIPs。
Endpoint 是隧道外层要到达的 UDP 地址。若这个地址又被选进隧道的目的前缀，发往节点的外层包可能被路由回隧道自身。客户端常为 Endpoint 保留一条更具体的直连路由；读配置时要把「外层地址」和「内层前缀」分成两列。
误读 3：两个对端写同一个前缀就能负载均衡。
同一个目的前缀只能属于一个对端。把相同前缀再写给第二个对端时，它会从第一个对端移走，而不是并列转发。长度不同的前缀可以共存，发送时按更长的前缀匹配，而不是按防火墙规则那种「先写先生效」。
误读 4：服务端上的 /32 是在限制用户能访问的网站。
服务端为每个客户端写一条其隧道地址的 /32，是在声明「这个内层源地址属于这把公钥」。客户端能访问哪些目的地，取决于服务端自己的转发、NAT 与防火墙，不取决于这一条 /32 本身。
误读 5：改 AllowedIPs 就等于改完了系统路由。
商业客户端、手机系统 VPN API 和 wg-quick 的安装方式不同。2026 年 9 月应以本机路由表里实际指向隧道接口的前缀为准，而不是只看配置文件里的字符串。
读一条配置时怎么核对
核对口径：2026 年 9 月，在已经连通的设备上同时看三列：对端公钥、Endpoint、AllowedIPs；再看系统路由里哪些前缀指向 WireGuard 接口。不要用生产密钥截图外传。
按这个顺序问：
- 身份：这一行公钥是节点，还是另一个客户端？
- 外层：Endpoint 是否只出现在 UDP 地址上，而没有被当成内层目的前缀？
- 出站：0.0.0.0/0 与 ::/0 是否都写了？只写 IPv4 时，IPv6 是否仍直连？
- 入站：对端被允许的源地址，是不是它真正使用的隧道地址，而不是一长串网站？
- 重叠：同一前缀是否出现在两个对端上？
- 和分流的边界：你想按应用排除的流量，是否其实要在另一层规则里写，而不是塞进 AllowedIPs？
本站只解释路由选择器的含义，不提供规避执法的具体指导，也不对具体客户端作推广。把 AllowedIPs 读成「哪组内层前缀属于这把公钥」，把 0.0.0.0/0 读成「默认路由进这个对端」，才不会把它误当成防火墙名单。更宽的隧道模型见 VPN 是什么。