上个月刚换了 VSOL V2802RH ，省心了。

运营商疑似上设备，对猫棒光特性阻断了。。手头几根猫棒在某个时间点后，就死活注册不上了，卡 o2o3 循环
在此之前也是稳定可用，有几个月时间路由日志观察到一天会被踢掉几次 pppoe ，某天我作死重启它，然后就再也无法注册了。。换其他猫棒插入也一样无法注册

死心了。

观点和理解和我感受基本一致，未来人类更多应该做的是架构设计，然后管理、约束 agents 让他自我完成循环，减少人工介入

开发新功能的时候，人类通过提供方向性和 idea ，和 agent 探讨，再确定 plan ，最后交给它们（ subagents/parallel ）执行并且做些基础验证（语法、功能完整性）

至于 debug/验收过程，也被极大的加快了，加日志，分析日志比人类快多了。。（当然有些关键点还是要自己提醒它

review 代码，也可以慢慢约束形成各种语言的规范

claude code 每次的新功能，几乎都精准切中发展路径: Memory -> Plan -> MCP -> Skills(发布顺序未经过严格求证)，夸张点讲它是 Coding Agent 工业标准也不为过？

claude code + 国产廉价模型，让成本降低，更多人能享受，探索更多可能，也为创造增加了非常多可行性。典型的量变引起质变。

看笑了，中转站老板们赚着网络和信息差的利润，心底上对这些客户，大抵是觉得都是*韭菜，对于一大堆无法解决网络问题或者不是专业的用户，要是这些服务都能正常在国内使用，有他们什么事？没点 x 数

@AkinoKaedeChan #27 还记得这事儿的，都是老网民了，确实这么多年一点没变：伸手党大骂“为爱发电”怎么不单独给我发电。哎！

配置复杂度、文档确实是个问题，不过折腾完一轮之后还是挺舒服的。。。

json 目前我是用 json5 模板写注释和行尾","支持(对于这两点用 jsonc 也可以)，然后用 python 写脚本填充 outbounds （按照自己的需求过滤、重新组织不同的 rule-set 来对应不同的 outbounds ），最后 json.dumps 出 json 格式的，这样不会有什么问题

面向移动设备(iOS)、透明旁路网关、服务器 docker compose 使用分别有几份稍微有点差异的模板，不过都是代码生成问题不大，每次调试修改通用规则稍微麻烦点，改完网关的，再用 beyond compare 对比差异保留差异中对特定模板有用的部分。

@liuzimin #18 我阿里和腾讯都是 2G ，反正够用了，没啥正经业务跑，都是玩

@liuzimin #5

我大概不到 10 个 peer ，腾讯云轻量上面的自建，docker stats 还行吧，另外 zitadel 是可以被替换成 authelia 的，不过目前非正式官方支持的方案，确实会免费些。

用起来很舒服，全 mesh 默认，精细化路由控制就要学习。

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
5752fe8f3db1 netbird_zitadel 0.68% 92.08MiB / 1.921GiB 4.68% 48.6MB / 51.7MB 20.5MB / 0B 9
414631130acf netbird_management 0.00% 32.24MiB / 1.921GiB 1.64% 266kB / 231kB 7MB / 77.8kB 8
968c0788df62 netbird_caddy 0.05% 24.06MiB / 1.921GiB 1.22% 6.58MB / 7.28MB 11.5MB / 32.8kB 9
7369b2125b18 netbird_coturn 0.02% 18.26MiB / 1.921GiB 0.93% 0B / 0B 4.04MB / 4.1kB 7
2f5b5dfa6cbc netbird_relay 0.00% 5.09MiB / 1.921GiB 0.26% 261kB / 356kB 0B / 0B 8
b5e21cd948fa netbird_zdb 2.26% 27.17MiB / 1.921GiB 1.38% 51.4MB / 48.4MB 15.6MB / 81.3MB 6
5b178be7154d netbird_dashboard 0.01% 25.48MiB / 1.921GiB 1.30% 137kB / 1.39MB 13.6MB / 61.4kB 4
2761ab3261a0 netbird_signal 0.01% 9.625MiB / 1.921GiB 0.49% 1.81MB / 1.19MB 0B / 0B 8

@tianwm #12 合理，我家也是基本同等位置，老的 WIFI6, TPLINK TL-XAP3020GC ，按现在时间买，那就上 BE5100 。
至于 AC 不需要，两个开 Fat AP ，802.1 k v r 都开上，不追求极致的漫游切换延迟，基本还好。纠结再搞多个 AC100v4 以上，AP 再开 Fit AP @llexus

@JoeSmith #32 实际上这么干之后，你会发现。。。还不如套个 sing-box 加配置来的简单。。。这玩意开 tun ，监听 dns ，ipset domain 之类的玩法，足够做很细的分流，用 clash api 开个 zashboard ，又能有 ui 管理。实际上还是挺省事的，至少日常切换不至于需要敲代码，至于改配置，倒是挺恶心的人的 json... v4/v6 都能用，不过我只用了 v4 only 。底层原理其实和你说的方案应该是一致的。

@badgv 容器确实多了，看起来比较臃肿，但效果确实好啊。。。也可能是我没用好 tailscale ，浅尝辄止

当时的场景是 wrt 旁路上装 sing-box tun + tailscale/netbird 测试，可能是没配置好 sing-box 导致的经常 relay 也说不定，
折腾到现在能稳定 netbird p2p ，估计再换回 tailscale 也许很顺利，不一定了，有时间再折腾过。。

@Csheng tailscale derp 自建，两边 peer 都有公网的情况下也经常跑转发，真沙雕。。。

试试 https://netbird.io/ ，tailscale 自建搞起来比这玩意还麻烦
目前我用它自建，所有 peer 都连自建，还是挺稳定的 P2P 连通，再不济都能转发。

@dangyuluo pfsense 没玩过。。我目前使用 routeros 做主路由，代替你 pve 中的 pfsense 。。
另外额外开了个 openwrt 跑小猫咪，需要 xx 的设备通过 mac 地址配置 dhcp options ，指向 openwrt 网关，只有自己的设备流量过 openwrt ，也够用了。。

@dangyuluo unifi 退烧了，公司买了 10 几个。。稳定倒是没太大问题，但。。似乎也没太必要，主要是买不起 10G 的口。。现在这个时代还用着 wifi6,1G 口的 ap 感觉比较坑

@dangyuluo
AP 是靠 DHCP 那两个 Options 来拿到 IP 的
AC 本身是个 DHCP Client ，关 DHCP 指的是它的 DHCP Server 。。。AC 也可以手动设置固定 IP

另外。。我后面搞两个蛋疼的用法。。在 ros 单独开多一个子网出来，把 5408pe 的 wan 口分配另外一个子网，这样能上网也能用云管理。。就是从路由器插了两根线到 5408pe ，总觉得很弱智。。

最近搞了个 ac100 ver4.0 ，打算把这玩意出掉了。。

@Csheng 这玩意有个坑就是，最少也要有一个 WAN ，也就是如果做交换机，只能用 7 个口。
且，无法云管理，或升级，因为交换机本身已经无法联网了，无论怎么加路由规则都是如此。

@ChristianSwift 嗯，我自己也是做了设置，目前在使用中。

Option 60 TP-LINK
Option 138 AC 的 LAN IP 地址比如 10.2.2.1

@caomu 感谢，一段时间没看，家里已经顺利完成布局。最后采用了小燕科技的零火开关，智能射灯，开关触发控制，控制射灯驱动以达到控制灯的目的，墙壁开关加其他输入控制，手机端也可以操作，省心很舒服。

在没有物理线路能互联的情况下
zerotier/n2n 打洞当成局域网用吧