/tag/双栈

家宽没固定公网 IPv4 也能稳定挂 5 个 Web 服务（Cloudflare 307 + Lucky STUN 双栈方案）

LinuxDo 最新话题 · 2026-05-17 22:53:31+08:00 · tech

写在前面，全文由 ANY大善人的opus4.7主导 IPV4 NEWAPI IPV6NEW直连佬友们好。分享一下我这边的家宽双栈对外方案，脱敏整理出来给有同样需求的同学参考。我家这边情况大概是：广东移动运营商给了公网 IPv6，但 IPv4 是大内网 NAT1，没固定公网 IPv4 想把家里 5 个 Web 服务（api / cpa / yx / code / claw）和 1 个 VPN 挂到公网要兼顾公司 IPv4 （办公网、IPv4-only 环境）和 IPv6 用户不想为这事单租 VPS 折腾完之后稳定跑了一阵，整理出来发上来。所有真实域名、公网 IP、动态端口、密钥都用 <...> 占位符替换了，自己用的时候换成真值即可。整套方案的免费成本：Cloudflare DNS + 307 Redirect Rule 在免费计划够用，Lucky 是开源的。零 VPS 开支。一、整体思路核心三招：双域名分离：入口域名（橙云）和落地域名（灰云）分开。入口只做 307 重定向，不直连后端；落地域名灰云直接 DNS 解析到家里。双栈分流：IPv4 客户端被 307 重定向到 service.stun.<ROOT_DOMAIN>:<STUN_TCP4_PORT> （家宽 IPv4 不能直 443，只能走 Lucky STUN 拿到的动态端口）；IPv6 客户端被 307 重定向到 service.stun.<ROOT_DOMAIN> （默认 443，直连 OpenWrt 公网 IPv6）。 VPN 独立：VPN 不走 307，因为 WireGuard 不理解 HTTP 重定向。VPN 用独立的灰云 AAAA 直连。二、主链路图 ┌────────────────────────────────────┐ │ Client / Browser / App │ │ service.<ROOT_DOMAIN> │ └──────────────────┬─────────────────┘ │ ┌──────────────────▼─────────────────┐ │ Cloudflare │ │ proxied entry records │ │ Dynamic Redirect, HTTP 307 │ └──────────────────┬─────────────────┘ │ ┌────────────────────────────────────────────────┼────────────────────────────────────────────────┐ │ │ │ ┌───────▼────────────────────┐ ┌──────────▼──────────────────┐ ┌──────────▼──────────────────┐ │ IPv4 client │ │ IPv6 client │ │ VPN client │ │ target should include port │ │ target uses default 443 │ │ no HTTP redirect │ └───────┬────────────────────┘ └──────────┬──────────────────┘ └──────────┬──────────────────┘ │ 307 Location: │ 307 Location: │ │ https://service.stun.<ROOT_DOMAIN>:<STUN_PORT>/path │ https://service.stun.<ROOT_DOMAIN>/path │ │ │ │ ┌───────▼────────────────────┐ ┌──────────▼──────────────────┐ ┌──────────▼──────────────────┐ │ DNS-only A │ │ DNS-only AAAA │ │ DNS-only AAAA │ │ service.stun.<ROOT_DOMAIN> │ │ service.stun.<ROOT_DOMAIN> │ │ vpn.<ROOT_DOMAIN> │ │ -> STUN public IPv4 │ │ -> OpenWrt public IPv6 │ │ -> OpenWrt public IPv6 │ └───────┬────────────────────┘ └──────────┬──────────────────┘ └──────────┬──────────────────┘ │ │ │ ┌───────▼────────────────────┐ ┌──────────▼──────────────────┐ ┌──────────▼──────────────────┐ │ Lucky STUN tcp4 │ │ OpenWrt │ │ OpenWrt VPN service │ │ public IPv4:<STUN_PORT> │ │ Lucky HTTPS :443 │ │ WireGuard/OpenVPN/etc. │ │ -> Lucky HTTPS :18443 │ │ cert *.stun.<ROOT_DOMAIN> │ │ protocol-specific port │ └───────┬────────────────────┘ └──────────┬──────────────────┘ └─────────────────────────────┘ │ │ └───────────────────────────────┬────────────────┘ │ ┌──────────────▼───────────────┐ │ OpenWrt Lucky reverse proxy │ │ same Host rules on 443/18443 │ │ service.stun.<ROOT_DOMAIN> │ │ -> backend │ └──────────────┬───────────────┘ │ ┌───────────────────────────────┼───────────────────────────────┬───────────────────────────────┐ │ │ │ │ ┌───────▼────────────────────┐ ┌────────▼───────────────────┐ ┌────────▼───────────────────┐ ┌────────▼───────────────────┐ │ api.stun.<ROOT_DOMAIN> │ │ cpa.stun.<ROOT_DOMAIN> │ │ yx.stun.<ROOT_DOMAIN> │ │ code.stun.<ROOT_DOMAIN> │ │ -> <APP_NODE_A>:8881 │ │ -> <APP_NODE_A>:8317 │ │ -> <APP_NODE_A>:5001 │ │ -> <APP_NODE_B>:19080 │ │ NewAPI │ │ CPA / Proxy API │ │ YX Web │ │ code-server │ └────────────────────────────┘ └────────────────────────────┘ └────────────────────────────┘ └────────────────────────────┘ │ ┌──────────────▼───────────────┐ │ claw.stun.<ROOT_DOMAIN> │ │ -> <APP_NODE_B>:18789 │ │ OpenClaw Gateway │ └──────────────────────────────┘ 解读：客户端先打入口域名（橙云），被 Cloudflare 307 到对应的 stun 落地域名 IPv4 客户端拿到 https://service.stun.<ROOT_DOMAIN>:<STUN_TCP4_PORT>/... ，解析到 Lucky STUN 公网 IPv4:动态端口，进 Lucky 反代 IPv6 客户端拿到 https://service.stun.<ROOT_DOMAIN>/... （443），解析到 OpenWrt 公网 IPv6，进 Lucky 反代两条路最后都汇到 OpenWrt Lucky 反代，按 Host 把请求转给内网真正的后端服务 VPN 走自己那条路，跟 HTTP 没关系三、DNS 怎么设入口域名（5 个）—— 橙云 api.<ROOT_DOMAIN> A proxied=true TTL=auto cpa.<ROOT_DOMAIN> A proxied=true TTL=auto yx.<ROOT_DOMAIN> A proxied=true TTL=auto code.<ROOT_DOMAIN> A proxied=true TTL=auto claw.<ROOT_DOMAIN> A proxied=true TTL=auto 为什么橙云：必须橙云，Cloudflare 只有收到 HTTP 请求后才能执行 Redirect Rule。灰云的话客户端绕过 CF 直接打到 A 记录，Redirect Rule 根本触发不了。入口的 A content 没那么重要（反正是 CF 边缘 IP 收的），不需要指向家里。落地域名（5 个 + 1 个 VPN）—— 灰云 api.stun.<ROOT_DOMAIN> A=<STUN_PUBLIC_IPV4> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 cpa.stun.<ROOT_DOMAIN> A=<STUN_PUBLIC_IPV4> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 yx.stun.<ROOT_DOMAIN> A=<STUN_PUBLIC_IPV4> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 code.stun.<ROOT_DOMAIN> A=<STUN_PUBLIC_IPV4> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 claw.stun.<ROOT_DOMAIN> A=<STUN_PUBLIC_IPV4> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 vpn.<ROOT_DOMAIN> AAAA=<OPENWRT_PUBLIC_IPV6> proxied=false TTL=60 为什么灰云 + TTL 60：307 之后客户端要直连家里 Lucky，必须灰云让 DNS 真实解析过去。TTL 60 是为了 STUN 公网地址变化时尽快收敛（用 LuckyDDNS 自动更新 DNS A 记录）。5 个落地域名的 A 都指向 Lucky STUN 探出来的公网 IPv4，AAAA 都指向 OpenWrt 公网 IPv6，这样一张通配证书就能盖住。四、Cloudflare Redirect Rule Cloudflare 控制台 → Rules → Redirect Rules，建一个 Dynamic Redirect Ruleset，phase 是 http_request_dynamic_redirect 。整体设置： status_code: 307 preserve_query_string: true 为什么 307：307 会保留 HTTP 方法（POST/PUT/PATCH），API 调用、表单提交、code-server 的 PUT 都不会被吃掉。301/302 在某些客户端会把 POST 改成 GET，直接坑死。为什么 preserve_query_string：不开的话 ?token=... 、 ?folder=... 这种查询参数全丢，API 和 code-server 直接报错。下面三条规则，按顺序放。规则 1：cpa 根路径补全 match: http.host == "cpa.<ROOT_DOMAIN>" and path == "/" target: https://cpa.<ROOT_DOMAIN>/management.html 为什么这么设：cpa 的根路径默认不会跳到管理页，先把 / 补成 /management.html ，后面通用规则继续接管把它跳到 stun 落地域名。规则 2：IPv4 入口加 STUN 端口 match: http.host in {api.<ROOT_DOMAIN>, cpa.<ROOT_DOMAIN>, yx.<ROOT_DOMAIN>, code.<ROOT_DOMAIN>, claw.<ROOT_DOMAIN>} and ip.src in 0.0.0.0/0 target expression: wildcard_replace( http.request.full_uri, "*://*.<ROOT_DOMAIN>/*", "https://${2}.stun.<ROOT_DOMAIN>:<STUN_TCP4_PORT>/${3}" ) 为什么这么设： ip.src in 0.0.0.0/0 是 IPv4-only 匹配。家宽 IPv4 走不了 443，必须把 Lucky STUN 当前公网端口写到 Location 里。 <STUN_TCP4_PORT> 是动态值，要靠脚本或 Webhook 同步过来（见第九节坑 2）。规则 3：IPv6 入口直接 443 match: http.host in {api.<ROOT_DOMAIN>, cpa.<ROOT_DOMAIN>, yx.<ROOT_DOMAIN>, code.<ROOT_DOMAIN>, claw.<ROOT_DOMAIN>} and not ip.src in 0.0.0.0/0 target expression: wildcard_replace( http.request.full_uri, "*://*.<ROOT_DOMAIN>/*", "https://${2}.stun.<ROOT_DOMAIN>/${3}" ) 为什么这么设：IPv6 客户端可以直达家里 OpenWrt 公网 IPv6 的 443，不需要动态端口，省事。五、Lucky 配置 STUN tcp4 类型: tcp4 Target: <OPENWRT_LAN_IP>:18443 (指向 Lucky 自己的 HTTPS 监听口，不是 443) PublicAddr (Lucky 探出来): <STUN_PUBLIC_IPV4>:<STUN_TCP4_PORT> 为什么 Target 是 18443 不是 443：家宽 IPv4/443 实测不通，IPv4 数据面只能走 Lucky 自己单独起的 HTTPS 监听口 18443。443 留给 IPv6 直连用。端口同步：STUN 端口是运营商分配的，动态值。Lucky 探到新端口后必须同步到 Cloudflare Redirect Rule 的规则 2。两种方式： Lucky Webhook → 调用 Cloudflare API PATCH Ruleset 外部脚本轮询 Lucky API → PATCH Ruleset 同步完后必须用 curl -4 -I 从外部复测 Location（见第九节坑 3，API 和边缘可能短暂不一致）。 HTTPS 双监听 Lucky 反代要同时挂两个 HTTPS 监听口：监听 1: <OPENWRT_PUBLIC_IPV6>:443 给 IPv6 客户端直连监听 2: <OPENWRT_LAN_IP>:18443 给 STUN tcp4 把 IPv4 流量打进来两个口共用同一组反代规则，因为 IPv4 和 IPv6 路径最后到 Lucky 时 Host 都是 *.stun.<ROOT_DOMAIN> 。通配证书类型: 通配证书 *.stun.<ROOT_DOMAIN> 签发方式: DNS-01 DNS Provider: Cloudflare (用 API Token，只给 Zone DNS Edit 权限) 为什么 DNS-01：HTTP-01 要 80/443 开放给 ACME，家宽 80/443 路径本来就不全通，DNS-01 不依赖入站端口，能自动续签。一张通配盖住 5 个 stun 落地域名。反代规则每个 stun 落地 Host 对一个内网后端： api.stun.<ROOT_DOMAIN> -> http://<APP_NODE_A>:8881 (NewAPI) cpa.stun.<ROOT_DOMAIN> -> http://<APP_NODE_A>:8317 (CPA / Proxy API) yx.stun.<ROOT_DOMAIN> -> http://<APP_NODE_A>:5001 (YX Web) code.stun.<ROOT_DOMAIN> -> http://<APP_NODE_B>:19080 (code-server) claw.stun.<ROOT_DOMAIN> -> http://<APP_NODE_B>:18789 (OpenClaw Gateway) 公共选项：前端协议: https 后端协议: http (TLS 在 Lucky 终止，后端走明文省事，不用每个后端搞证书) WebSocket: 开 (code-server 这种长连接工具必须开) 自动反代重定向: 关 (避免后端 Location 头被二次改写，排障痛苦) 访问日志: 开 (出问题方便看) 为什么 TLS 在 Lucky 终止：证书、SNI、续签集中维护一处，后端跑明文 HTTP 反而干净。六、认证保护公网第一道认证放在 Lucky，不放在 Cloudflare 入口层（CF 只做 307 不挡）： api.stun.<ROOT_DOMAIN> Lucky Basic Auth: 关后端自己有登录页 (NewAPI) cpa.stun.<ROOT_DOMAIN> Lucky Basic Auth: 开后端通过 Basic Auth 后到 CPA API yx.stun.<ROOT_DOMAIN> Lucky Basic Auth: 开后端通过 Basic Auth 后跳 /login code.stun.<ROOT_DOMAIN> Lucky Basic Auth: 开 code-server 后端 auth=none claw.stun.<ROOT_DOMAIN> Lucky Basic Auth: 开后端是 OpenClaw Gateway UI 为什么 api 不开：NewAPI 自带账号系统，再叠一层 Basic Auth 反而碍事。为什么其他都开：cpa/yx 是私有管理类入口，code-server 直接是命令执行入口（裸露公网 = 送服务器），claw 是网关 UI。统一拿 Lucky Basic Auth 当公网第一道挡板，简单粗暴。为什么 code-server 设 auth=none ：code-server 自带密码方案不够灵活，统一交给前置 Basic Auth 处理。前提是 Lucky Basic Auth 必须开，否则 code-server 在公网完全没保护。顺嘴提一下：我账号下还有 2 个 Cloudflare Access SaaS/OIDC App，但那是给 Lucky 自己做第三方登录用的回调端点，不是业务入口拦截页。业务入口前没有 CF Access。七、VPN 为什么不能套 307 vpn.<ROOT_DOMAIN> AAAA -> <OPENWRT_PUBLIC_IPV6> 灰云直接灰云 AAAA 指向 OpenWrt 公网 IPv6，按 VPN 自己协议端口（WireGuard / OpenVPN / IPsec）连。为什么不能走 307：307 是 HTTP 状态码，只有浏览器/curl 会跟随 Location。WireGuard/OpenVPN 客户端根本不解析 HTTP，把 VPN 域名扔进 Cloudflare 橙云 → 客户端连不上 → 超时。VPN、SSH、其他非 HTTP 协议都不要套 Cloudflare 307。八、验收 curl 每条命令独立可复制粘贴，把 <...> 换成真值即可。 # 入口域名是不是返回 307 curl -I https://api.<ROOT_DOMAIN>/some-path # IPv4 Location 必须带 :<STUN_TCP4_PORT> curl -4 -I https://api.<ROOT_DOMAIN>/some-path # IPv6 Location 应该不带端口 curl -6 -I https://api.<ROOT_DOMAIN>/some-path # IPv4 STUN 落地是否可用 curl -4 -k -I https://api.stun.<ROOT_DOMAIN>:<STUN_TCP4_PORT>/ # IPv6 443 落地是否可用 curl -6 -k -I https://api.stun.<ROOT_DOMAIN>/ # Lucky Host 规则是否命中 (LAN 内测) curl -k -H "Host: api.stun.<ROOT_DOMAIN>" https://<OPENWRT_LAN_IP>:18443/ # Basic Auth 是否生效 (期望 401 + WWW-Authenticate) curl -I https://code.stun.<ROOT_DOMAIN>:<STUN_TCP4_PORT>/ 九、踩过的坑坑 1：IPv4 走不了 443 家宽 IPv4 是大内网 NAT，公网 443 不通。一开始以为 IPv4 也能走 443，折腾半天 timeout。最后老老实实用 Lucky STUN tcp4 拿一个动态公网端口，把 Cloudflare Redirect 的 Location 写成 :<STUN_TCP4_PORT> 才通。坑 2：STUN 端口是动态的 Lucky STUN PublicAddr 的端口运营商会换。如果 Cloudflare Redirect Rule 里写死旧端口，IPv4 用户会被重定向到失效端口，表现就是"网页打不开"。必须做端口同步：Lucky Webhook 或外部脚本 PATCH Cloudflare Ruleset，同步完用 curl -4 -I 验证 Location 是否真的带新端口。坑 3：Cloudflare API 配置和边缘行为可能短暂不一致 PATCH 完 Ruleset，Cloudflare API 返回的 target_expression 显示带端口，但边缘 HTTPS 实际返回的 Location 没带端口，IPv4 用户继续 timeout。这种漂移可能持续几分钟。别只看 API 返回值，必须从外部 curl -4 -I 看最终 Location 才算数。坑 4：Lucky 404 不一定是后端挂了直接访问 Lucky 监听口或 Host 不匹配会返回 Lucky 自己的 404/Warning 页。第一反应别去重启后端，先确认 Host 头是不是命中了反代规则： curl -k -H "Host: api.stun.<ROOT_DOMAIN>" https://<OPENWRT_LAN_IP>:18443/ 加上正确 Host 才能命中规则。坑 5：VPN 不能套 Cloudflare 307 前面讲过：VPN 客户端不理解 HTTP 重定向，必须独立灰云 AAAA 直连，按 VPN 自己协议处理。坑 6：排障先分清 timeout / 404 / 401 timeout ：网络层问题（端口没开、IPv4/443 路径、NAT 失效、防火墙） 404 ：Host 没命中 Lucky 反代规则（多半是 Cloudflare Redirect 写错了 stun 域名，或者直接打了 Lucky 监听口没带 Host） 401 ：规则命中了，Lucky Basic Auth 在工作，这是正常表现别把 401 当成"挂了"去重启服务。十、完整脱敏抽象架构图 ┌────────────────────┐ │ client │ └─────────┬──────────┘ │ ┌─────────▼──────────┐ │ Cloudflare orange │ │ HTTP 307 only │ └─────────┬──────────┘ │ ┌───────────────────────┴───────────────────────┐ │ │ ┌─────────▼──────────┐ ┌──────────▼─────────┐ │ IPv4 path │ │ IPv6 path │ │ stun host + port │ │ stun host + 443 │ └─────────┬──────────┘ └──────────┬─────────┘ │ │ ┌─────────▼──────────┐ ┌──────────▼─────────┐ │ Lucky STUN tcp4 │ │ OpenWrt IPv6 │ │ public:<port> │ │ Lucky HTTPS 443 │ └─────────┬──────────┘ └──────────┬─────────┘ │ │ └───────────────────────┬───────────────────────┘ │ ┌─────────▼──────────┐ │ Lucky reverse proxy│ │ Host based routing │ └─────────┬──────────┘ │ ┌────────────────────────────┼────────────────────────────┐ │ │ │ ┌───────▼────────┐ ┌────────▼───────┐ ┌─────────▼──────┐ │ service A │ │ service B │ │ service C │ │ node A:port │ │ node A:port │ │ node B:port │ └────────────────┘ └────────────────┘ └────────────────┘ 写在最后整套方案核心就这几条：入口必须橙云，落地必须灰云 IPv4 走 STUN 端口，IPv6 直接 443，别假设 IPv4 能走 443 307 + preserve_query_string，API 和长连接才不挂 VPN 独立，别套 307 认证放在 Lucky，不放在 CF 入口 STUN 端口动态值，必须同步 + 外部复测所有 <...> 占位符替换成真实值再用。真实域名、公网 IP、STUN 端口、Cloudflare Zone ID、API Token、Lucky 管理凭据、Basic Auth 账号密码、TOTP 种子、origin 旁路密钥这类敏感信息绝对不要贴论坛，包括截图里也要打码。有问题评论区交流，佬友们如果有更优雅的 STUN 端口同步方案也欢迎贴出来。 2 个帖子 - 2 位参与者阅读完整话题