试试 dagu ，但是简陋到连登录啥的都省了，可以二开做一些事情
https://github.com/dagu-org/dagu

你可能缺的是个 ci/cd ，当你有了在线的自动构建以后，你会懒得在本地构建，啥都想提交到云端去构建，然后有这个做动力就忘不了 commit 了(逃

云服务器可以直接通过写盘重装系统，之前在云主机上试过装 openwrt ，感觉很奇怪，但是能跑。

environment 或者 variable?
配置一个环境变量(不是 os 的那个，是 postman 自己的概念)，然后拿着变量去构造 url 。需要替换的时候就改环境变量就行了。

VSCode + thunder client
后者 js 写的插件，需要花些时间破解掉 50 个请求的限制和不升级不让用，基本可以实现纯离线的 API 调试工具，支持 curl 导入、pre-scripts 、env 、code-gen 这些 postman 基础功能，也支持导入 postman 的导出文件。

@kyonn nodered 其实算是那种低代码平台，拖拉拽实现一个流程。只是玩智能家居的有不少没能力写代码的，促成了 nodered 在这个圈子的繁荣。

之前用 cronicle ，优点是可以通过插件扩展出很多种执行器，缺点是连 docker 官方都没支持，得自己写插件实现 nodejs 调用 docker ，之前也自己搓出来了这个插件。

直到某天误操作 rm -rf 了(操作效果类似，但不是 rm -rf)，懒得重新研究文档写插件了，发现了一个新的异步任务调度工具 Dagu

Dagu 本质上是一个 DAG 工具，即有向无环图调度工具，因为是 golang 搓的，它原生支持 docker 所有参数，用 yaml 定义 DAG ，然后逐个节点执行。缺点嘛，就是这东西轻量到可以称之为简陋，没有汉化，甚至没有一个 icon ，执行器方面你得把代码打包成服务(走 HTTP 触发器)或者 docker 镜像它才能调用(或者在 yaml 里搓 shell 脚本)，前者内存常驻和 cronicle 其实无差了，后者还得自建 docker registry ，当然我的话是有搭建 gitea ，它本身带一个简化的软件包管理，支持 docker 镜像托管，搭配上 gitea action 自动构建镜像，用 dagu 去自动拉镜像执行还是挺舒适的。

Dagu 项目地址:https://github.com/dagu-org/dagu

PS:打到这，其实如果有 gitea 了，搭一个 gitea action 让它定时执行也不是不行哈。

@Puteulanus 卧槽亮瞎我狗眼

层主可能需要的是一个 pastebin 。纯静态站点想不太出来输入的数据怎么留到下一次访问，既然客户端重启就重置，那么 localstorage 这种浏览器内的本地存储大概也会被重置，想留下数据就只能靠后端，但是这又是个静态页面，没有后端。还是说层主只需要一个页面，在单次开机周期内能留下数据就行。

pastebin 的话就是专门给你个地方去保存剪贴板里无处安放的数据，因为功能很简单，就算有后端也很轻量，可以考虑在路由器上部署。

另外还有个骚路数，就是让 ai 给你写个 luci 插件，实现一个文本框，里边能保存一些数据，然后数据直接用 openwrt 那个配置管理 uci 存或者/tmp 下或者哪的开个文件存。认证就靠 op 的登录，配一个强密码，主打一个数据和路由器配置共存亡。

@JerryYuan 用这点性能损耗换快照这些功能还是很值的。

@YsHaNg 现在的虚拟机都是靠专门的虚拟化指令集实现的了，效率已经接近 99%了，损耗几乎可以忽略不计了。现在云厂商，再加个最基础的芯片去做虚拟化控制器，甚至都能做出 100%效率的虚拟机了。

建议选一个 pve 或者 esxi 这种，没啥可折腾的虚拟化系统做整个家庭私有云服务的底座，折腾的越少越稳定。同时虚拟化平台还可以提供快照这一粒重要的后悔药。

然后包括 NAS ，还有计算节点都在其上另开虚拟机。磁盘啥的可以直通进虚拟机，部署 NAS 系统可以和物理机一样的。

目前我就是 PVE 做底座，其上部署黑群(存储)+OpenWRT(网络)+Ubuntu(计算)，完全按括号里的拆分，群晖负责一切和存储/备份有关的操作，Ubuntu 负责一切数据处理工作，OpenWRT 负责一切和网络相关的工作。Ubuntu 挂载群晖的 NFS 卷作为 Docker 的持久化卷(Volume)，Openwrt 完成异地组网，VPN 一键回城。

建议还是研究下 IPv6 公网地址，直连的带宽和延迟不是转发能比拟的(可以多配置一条转发的路由备用)

回到题主的问题，所谓的 A 网络主机访问 B 网络主机实际包含两步，A 网络主机请求 B 网络主机，B 网络主机处理请求响应 A 网络主机(这一层很容易被忽视)

所以按题主配置，ping 包传输的整个链路应该是:

去程:
* A 网络主机→A 路由器 LAN(ICMP Request)
* A 路由器 LAN→A 路由器 WG0(ICMP Request)
* A 路由器 WAN→中转节点 WAN(wg 协议)
* 中转节点 WG0→中转节点 WG0(ICMP Request ，中转节点 wg0 也许能抓到，抓不到跳过也行)
* 中转节点 WAN→B 路由器 WAN(wg 协议)
* B 路由器 WG0→B 路由器 br-lan(ICMP Request)
* B 路由器 br-lan→B 网络主机(ICMP Request)

回程:
* B 网络主机→B 路由器 br-lan(ICMP Echo)
* B 路由器 br-lan→B 路由器 wg0(ICMP Echo)
* B 路由器 WAN→中转节点 WAN(WG 协议)
* 中转节点 wg0→中转节点 wg0(ICMP Echo)
* 中转节点 WAN→A 路由器 WAN(wg 协议)
* A 路由器 WG0→A 路由器 br-lan(ICMP Echo)
* A 路由器 br-lan→A 主机(ICMP Echo)

捋清楚完整的预期数据通路以后，就可以分段配置每一台设备，让数据包按预期流转。
这里引入一个调试技巧，即在整体不通时，在每一段两端的网络适配器抓包看看数据包走到哪一步就迷路了，找到迷路的那一步，对照发送的一侧适配器所在主机的路由表看看实际走到哪条路由上去了，一般修正这个路由表配置，数据包就能继续往前走了。所有链路都抓包确认成功以后，网络应该也就通了。

类似的场景，我是 docker 会解析 v6 导致不走梯子，加了个 AdGuardHome ，把 v6 解析过滤掉，明显就稳定多了。。。

@JerryYuan 当然自己学一下焊接还是性价比最高的

找个修手机的，给 50 块钱焊一个不包好坏的插座，看丝印应该是有对应的元件但是厂家没有出料。

创建索引应该简单写个 python 脚本，一律转成纯文本，丢进去分词做倒排索引就行了。目测是 chatgpt 能接受的强度

elasticsearch 最初就是程序员给老婆做的菜单检索引擎，也是稀碎的文件一大堆😄

@TashinV 从 openwrt 里边拷出来改下就行，里边有几个依赖 luci 配置的东西，可以改成用 wg-quick 啥的去操作。脚本本身已经够用了，没必要自己搓一个了。(如果 unifi 里边和 Linux 的逻辑一致的话)