客户端的开关已经打开，但哪些流量会进入隧道？WireGuard隧道设置需要同时考虑操作系统路由和 Peer 的 AllowedIPs。只看开关状态，无法判断一条访问请求最终走向哪里。
01 / 一个字段，两个方向
AllowedIPs 将地址前缀与 Peer 公钥关联，这就是 cryptokey routing 的核心。发送时，数据包先由系统路由决定是否进入接口；进入后，再按目标地址匹配 AllowedIPs 来选择 Peer。接收时，数据包完成解密认证后，还要检查其内部源地址是否属于该 Peer 允许的范围。
它既不是普通节点备注，也不能替代主机防火墙。配置 wg本身不等于已添加系统路由，wg-quick通常会根据 AllowedIPs 建立路由，并对默认路由做特殊处理；设置 Table=off则关闭这部分自动建路由行为。相关层次可结合隧道路由总览阅读。
02 / 先辨别地址与前缀
CIDR 的 /32 表示单个 IPv4 地址，/24 表示相应的 IPv4 网段；IPv6 单地址常用 /128。Interface 的 Address 是本机隧道地址，Peer 的 AllowedIPs 是与对方身份关联的地址范围，两者用途不同。检查本地局域网、目标内网和隧道网段，避免无意重叠。
| 配置位置 | 演示值 | 含义 |
|---|---|---|
| 服务端针对客户端的 Peer | 10.77.0.2/32 | 该客户端的隧道源地址与发往它的目标 |
| 客户端针对网关的 Peer | 10.77.0.1/32, 192.168.50.0/24 | 选择网关隧道地址和远端示例网段 |
| 客户端 IPv4 全隧道 Peer | 0.0.0.0/0 | 匹配全部 IPv4 地址，仍受系统路由策略影响 |
表中均为示例，不能直接照搬生产网络。服务端不应给每个普通客户端都填同一个 /0。发送选择通常遵循最长前缀匹配；不同 Peer 重复相同前缀会产生归属冲突，重叠前缀也可能带来非预期选择，应在设计阶段消除歧义。
03 / 分流从最小访问范围开始
若仅需访问远端某个网段，先把那个网段写入客户端的 AllowedIPs。将目标网络通过正确的 Peer 发出，只完成了去程的一部分；网关还需能转发、允许流量通过，并让目标网络知道如何回应。握手后仍不通时，继续看Linux 转发与回程路由，不要仅靠扩大 AllowedIPs 解决。
# 只读检查示例，目标地址须替换为自己的测试目标
ip route show
ip rule show
ip route get 192.168.50.10
sudo wg show wg0 allowed-ipsip route get可帮助确认系统当前选路，不能单独证明对端已允许接收该来源。记录变更前的路由表与策略规则，一次只改一个前缀。远程维护服务器时，不要无保护地改变默认出口，以免管理会话也被送入尚未验证的隧道。
04 / 全隧道不是通用默认答案
0.0.0.0/0只描述 IPv4；::/0描述 IPv6。没有可用的 IPv6 地址、路由、转发、回程和过滤策略，就不能保证追加 ::/0 后可用。只配置 IPv4 全隧道时，IPv6 可能继续沿系统原路径通信，应按自己的网络政策明确处理。
全隧道还需要网关出口能力、合适的返回路径和 DNS。尤其在分流中，选中的 DNS 服务器也必须有路由可达；其设置方式见客户端 DNS 与系统解析器。不要把域名解析成功等同于所有地址都已从预期接口发出。
05 / 用一条具体访问验证设计
选定一个经过授权的目标 IP，依次核对系统路由、发送 Peer、对端接收来源检查、目标返回路径。再选一个应走本地出口的地址做对照。保留“目标—预期接口—实际接口”的小表，而不是只写“已连接”。检查通过后再逐步扩展网段，遇到问题按已记录的前缀恢复。
