网络与流量分流

公网流量先到 Caddy，再按域名/路径交给应用；Xray 普通流量目前默认直连，没有额外的系统级透明代理。

Topology

请求路径

浏览器 / Cloudflare
        │
        ▼
      Caddy :80/:443
        ├── 7879710.xyz       → /var/www/html（门户 + Typecho/PHP）
        ├── 7879710.xyz/wiki  → /var/www/deployment-wiki（VPS 管理指南）
        ├── cpa.* /keeper     → 127.0.0.1:16796
        ├── cpa.* 其它        → 127.0.0.1:16791
        ├── dashboard.*       → 127.0.0.1:16795（Nezha / h2c）
        ├── api.*             → 127.0.0.1:16793（New-API）
        ├── sub2api.*         → 127.0.0.1:16794（Sub2API）
        ├── alist.*           → 127.0.0.1:16797（OpenList）
        ├── wiki.*             → /var/www/wiki/site（AI 项目知识库）
        └── disco.*           → 127.0.0.1:8443（Discovery）

Host network

主机网络事实

公网地址

eth0 使用公网 IPv4（/32）和上游网关；当前没有全局 IPv6，所以部分 IPv6 探测出现不可达属于预期现象。

DNS

解析链路

本机通过 systemd-resolved stub 解析，上游 DNS 与 DNS-over-TLS 由系统配置；启动时由持久化脚本应用到 eth0。

RULE

策略路由

ip rule 只有 local/main/default；没有 TProxy、TUN、WireGuard、Tailscale 或 sing-box 分流表。

Xray path

VLESS / SOCKS 路径

入站监听

VLESS Reality：:16798，TCP，XTLS Vision。
SOCKS5：:16799，启用 UDP。
Xray API：127.0.0.1:10085，仅本机。

当前路由

普通流量默认走 freedom/direct。
没有按域名、地区或 IP 的自定义规则。
API 标签流量由黑洞出站处理。

结论：目前所谓“分流”主要是 Caddy 的域名反代与 Docker 私网隔离；若要增加真正的国内外分流，需要另行设计规则、DNS 和故障回退策略。

Private networks

Docker 私网

网络	网段	成员	边界
`new-api_default`	`172.18.0.0/16`	New-API、Redis、PostgreSQL	数据库和缓存不直接对公网
`sub2api-deploy_sub2api-network`	`172.22.0.0/16`	Sub2API、Redis、PostgreSQL	应用通过 Caddy 暴露
`syncthing_default`	`172.23.0.0/16`	Discovery、Relay	Discovery 仅主机 8443 反代
`docker0`	`172.17.0.0/16`	默认桥	当前无主要业务成员

Exposure

防火墙与排查

UFW 基线

默认入站/转发拒绝、出站允许。已放行 Web 80/443、SSH 16792、NTP 123、Syncthing 相关端口和一段 16790–16799 的历史业务范围。

建议后续收窄端口范围

只读排查命令

ip -br addr
ip rule && ip route
sudo ufw status numbered
sudo ss -lntup
docker network ls

远程操作提示：networking.service 当前显示 failed，但 eth0 仍由现有配置维持在线。没有带外控制台时，不要直接重启整个网络服务。