今天刷菊花梨异色，大概2500球一直没有出，想着最后500球 先是补偿了 异色烟花团 清完盒子，重新攒满，第三个盒子直接开出 异色菊花梨 直接上炫彩， 居然是黑白炫彩！！！ 太激动了！！！ 2 个帖子 - 2 位参与者 阅读完整话题
我在家里部署的newapi v6 ddns + lucky 配置好。可以通过域名+端口 在v6环境下访问。我想着我刚搞了一个备案的域名就想用edgeone来加速一下,同时实现v4可以访问。 访问没问题。但是newapi上操作添加密钥或者添加渠道都没法显示出来。 如果用cf tunnel穿透那个域名这些东西都可以显示出来了。我就纳了闷了，不懂问题在哪。应该是edgeone配置问题，但不知道修改哪里。 9527是lucky端口 配置如图： 2 个帖子 - 2 位参与者 阅读完整话题
MindBase —— 开源的个人记忆中心，同步你与 AI 的上下文 GitHub: https://github.com/realuckyang/mindbase 官网: https://mindbase.me MindBase 是一个开源的记忆中心——同步你与 AI 的上下文。 🤖 AI 互通 — 内置可查询数据的 agent ，兼容大多数模型与市面上的各种 coding plan 。同时提供 OpenAPI 、MCP 、Skill 三种方式打通你与 code agent 的互通——你的 code agent 在工作中能了解你的上下文，记录做过什么，积累经验，更新项目状态，记住你的偏好等。 🌱 记忆有形状 — 记忆不是一条条抽象的数据，而是有自己形状、自己交互、自己功能的应用。内置 12 个应用，另有 40+ 免费模板可选，你还可以让 AI 快速开发属于你的记忆应用。 ☁️ 数据在你手里 — 快速部署在 Cloudflare 上，底层依托 Workers 、D1 、R2 ，免费额度足够日常使用。D1 内建 30 天时间点恢复，兜住 AI 误操作，让你更放心地让 AI 读写你的数据。 截图 应用 预置 12 个：主页 · 待办 · 笔记 · 记账 · 项目 · 个人档 · 大模型 · 指令集 · API · 邮箱 · 域名 · 足迹 另有 40+ 免费模板可在 mindbase.me 下载安装。模板里没有的，在「设置 → 新建应用」写下需求，自动拼出完整指令，交给 Claude Code 或 Codex 跑 npm run deploy 即可上线。 部署 Cloudflare 账号 + Node 22+： git clone https://github.com/realuckyang/mindbase cd mindbase && npm install npx wrangler d1 create mindbase npx wrangler r2 bucket create mindbase cp wrangler.example.jsonc wrangler.jsonc npx wrangler d1 execute mindbase --remote --file=schema.sql --yes npm run deploy 也可以把 README 丢给 Claude Code / Codex 一句话部署。 MIT 开源，欢迎试用和反馈。
写在前面，全文由 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 位参与者 阅读完整话题
大佬们好 介绍一下背景:家里云目前没有v4 在学校没有v6 想把v6的域名用frp转发出来用v4访问 https://ward.zyuo.cn:666 这个域名是可以用v6访问的 但是v4访问不了 我现在想用frp把 zyuo.cn:666 这一整段代理成v4 比如用 ward.frp.zyuo.cn:666或者 frp.ward.zyuo.cn:666 因为我不想每个网站搞一条隧道 想把所有的网站都放到zyuo.cn:666这一个端口上 我有点头脑风暴 不知道怎么搞了 有没有大佬可以教学一下 lucky反代出来的域名 chemlfrp的创建隧道 该咋填 4 个帖子 - 4 位参与者 阅读完整话题
从 [5 月 9 日 UI 全新升级] CPA-Manager 需求收集 & 开发进度同步 & FAQ 继续讨论： 之前在 CPA 默认端口中只能用内网地址或者 http 访问 CPA-Manager，不能用反代和 https 方式访问 CPA-Manager 的统计，研究了一下访问方法。 关于反代后 lucky，用 https，访问 cpa-manager 反代端口怎么设置 docker run -d –name cpa-manager –restart always – add-host < 域名 >:192.168.31.2 -p 28317:18317 -v cpa-manager-data:/data -e USAGE_CORS_ORIGINS=* seakee/cpa-manager:latest 192.168.31.2 nas 的是内网地址 lucky 添加以下子规则，并排序 /status → http://192.168.31.2:28317/status /setup → http://192.168.31.2:28317/setup /v0/management/usage → http://192.168.31.2:28317/v0/management/usage /v0/management/model-prices → http://192.168.31.2:28317/v0/management/model-prices 然后在 Usage Service 设置地址为： https://< 域名 >:[反代 port] 比如 https://www.baidu.com:[18317] 然后就可以用原来反代的地址和端口使用统计了。 4 个帖子 - 2 位参与者 阅读完整话题
目前的情况是这样的 参考这个帖子做的： https://yantao.wiki/archives/59/ 1、我的旁路由获取到了ipv6,然后我已经ddns到了cf代理的域名上了，然后开启了小橙云。 2、ssl开了严格模式。 3、Origin Rules 都试过自定义筛选跟全部传入 4、lucky配置了ssl 5、lucky也配置了web服务进行反代 访问一直报522，还请大佬指点 2 个帖子 - 2 位参与者 阅读完整话题
本地NAS部署Vaultwarden，有公网IPV6，有绑定域名，使用lucky反代，能通过域名打开Vaultwarden管理页面进了帐户创建，添加浏览器插件Bitwarden，选择自托管服务器域名进行登录报错，我以为是服务器可能需要IPV4才能访问，于是改用CF 隧道，还是出现同样的报错。有没有遇到群友遇到过相同问题 7 个帖子 - 6 位参与者 阅读完整话题
香港本地使用，发现用不了 Gemini ，而且谷歌搜索的结果一堆日文。
香港本地使用，发现用不了 Gemini ，而且谷歌搜索的结果一堆日文。
香港本地使用，发现用不了 Gemini ，而且谷歌搜索的结果一堆日文。
香港本地使用，发现用不了 Gemini ，而且谷歌搜索的结果一堆日文。
昨天是个lucky day，公司团建，不管有没有趣，只要不上班，那都是欢快的！ 再有，就是佬站抽奖，我中了！！！一台hk小鸡为期一月的使用权，感谢社区佬友馈赠，倍增了这个周末的愉悦~ 这周才凭github年限主动注册，一次通过小作文，作为新人，分享（水）一下小鸡的捣鼓情况，作为处女帖，希望大家捧场 机器1c1g20g，详细配置： PasteBin - VPS测评平台 工作中centos使用多，debian系用的少，初始环境设置下： 主机名 echo "ip hostname" >> /etc/hosts 时区 （时间不对） timedatectl set-timezone Asia/Shanghai 必要软件安装 (nano不适应/不熟，还是vi编辑器顺手) apt remove nano apt install vim apt install curl 安全加固 # 创建普通用户加入sudo组，为root禁止登录准备 useradd regularuser usermod -aG sudo regularuser # sshd_config配置调整 PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no # 重启sshd，安全期间建议保留一个登录，以免误被锁外面登录不了 # 安装fail2ban 安装v2ray，233boy的脚本一键安装 v2ray 一键安装完成，已输出 链接 (URL)，复制，粘贴到客户端url地址，即可畅游网路了 2 个帖子 - 2 位参与者 阅读完整话题