需要处理就就地处理，不需要处理的就上抛。如果你觉得没有需要你处理的错误。。
看实际情况吧，举个例子，web 服务，如果业务一路上抛错误，那么到 web server 的 handler 上，它会统一把这个错误处理成 500 Server error ，至于错误内的 stack 信息，完全取决于你自己实现。

虽然但是，TWT 和 OFDMA 压根没必要开，只开 MUMIMO 就行。

@BanShe
default bride：有线 LAN
wlan bride：AP 及无线设备/IOT 等
无线有更严格的 ACL 配置，包括禁止 IOT 设备主动访问 LAN 内设备，禁止一些“自带云服务”的 IOT 设备访问 WAN （ eg：摄像头接入的是本地 surveillance station ，不需要它的云服务）

同一个 LAN 下不开 ARP 又不太方便，开了 ARP 互访的路由 ACL 又没法写。所以干脆简单隔出来。
bridge vlan 要在 bridge 上搞一堆 vlan filtering 有点麻烦不如直接 vlan 桥到一个新网桥上完事。

side router：实际业务跑在物理接口的 vlan 下，之前调试的时候在 ROS/交换机口上换过位置，索性写个网桥方便拔线换接口时不用重新配置

@zealic
你描述的其实和 OP 用的没有本质区别，只不过你描述的 PolicyMode 可以省一个旁路的设备。

我不推荐 ROS 直接挂 WG 原因
一是，过墙能力差，很容易被针对。而且 ROS 本身的魔法能力，相比*ray/clash 等一堆 core 还是差了太多。
二是，这部分魔法流量走 PolicyRouting+WG 本质也是进用户态处理，会直接拉高 ROS 的负载。

走旁路的话，相当于魔法策略全部 offload 给旁路由，这样无论是带宽还是功能都是可以按需 scale 的。而不用考虑 ROS 本身的硬件负载能力。

@zealic
wg/zt 本身是不适合魔法场景的，过墙能力太差，ros 容器限制又太多，OP 的场景也是旁路由单独跑。

另外，旁路由模式不代表无法 fasttrack 呀，在 L3 拓扑上旁路由就是正常的下一跳，不加 mangle 的情况下是可以正常 fasttrack 的，LAN to ROS ，旁路由 to ROS wan 都可以正常 fasttrack

@zealic
mangle 如果要干预路由决策，需要 mark routing ，会直接导致 fasttrack 失效。
实际性能会比路由表更低，路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。

@jdjingdian
fullcone NAT 只支持 UDP 完全没问题啊。。TCP 各级路由基本都是 stateful tracking ，fullcone 意义在哪？
另外 EoIP ，IPIP ros 本身不是有么。。

组网的思路要打开，当下互联网协议基本僵化到只剩下 TCP 和 UDP 能用了，99.9%的需求*ray+tproxy 可以通杀。

没有

@TigerBest
国内教程一言难尽，很多都是照猫画虎没抓到问题本质。
一般来说关了 DHCP 是最稳妥的，因为“TP 这种硬路由”你没办法很精细的控制它的固件行为，如果他把物理 WAN 口上的地址划进路由表还设置了错误的 metric ，那你上网就会有各种奇奇怪怪的问题。

另外，在正确设置路由的情况，只需要把 LAN 的范围错开光猫的地址范围，哪怕不开 DHCP ，一样可以通过手动给接口添加 IP ，达到直接从路由器下访问光猫管理页的目的，压根不需要连光猫的 WiFi 才能管理。前提是你的路由器要能够进行路由表/防火墙的精细设置。
https://i.imgur.com/8foJjW3.png

了解一下逻辑接口和物理接口。
光猫，DHCP 下发地址在路由器的物理 WAN 口上（还得假设路由器接光猫的 DHCP ）

但是路由器拨号走的 pppoe 逻辑接口，这个逻辑接口只是隶属于物理 WAN 口。
而你的内网 192.168.1.0/24 在 LAN 上，通过路由器 NAT 从 pppoe 逻辑接口走默认路由上网，都不是一个接口，何况 tplink 的路由表里压根没有光猫的 192.168.1.1 的路由（拨号模式下，压根不吃你光猫 DHCP 给的地址），这能有什么冲突的？

不信你试试桥接还能不能在路由器下访问光猫管理页面，肯定访问不到吧。

如果不要求全屋制冷的情况下，中央空调远不如每个房间一个挂机省电。
以及，一般有一个最低功率，看你两个房间要的制冷量，如果不比这个高多少，那肯定 1-2 个房间区别不大

家用监控请不要碰任何和“智能/云”沾边的东西。除非你信任 7x24 监控你家的云服务商的良心。

@EGOISTK21 这个不能算误判，你考虑下 packet path ，你会发现是合理的。ROS 的 conn-track 是 stateful 的，对于 TCP 来说双向的数据报文都被 track 到，tcp 进入 establish 状态后路由器才会正常转发报文。
非对称路由在有状态防火墙上吃瘪是常事，我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。

你以为的股市
大环境，公司的发展和价值
实际的股市
大庄家割韭菜的镰刀

除非真的兵荒马乱企业倒闭了，现在的股市就是资本家的数字游戏。

@haixinsc 一天 1T 进去真不冤

旁路由模式推荐将旁路由和网关放在一个独立的网段内，否则下行流量（即由网关返回的响应）会直接由旁路由回复给 LAN 内的设备，造成非对称路由。
这在某些情况下可能会造成意想不到的问题。你这个 case 看起来就像是这样。

拓扑配置，可借鉴我自用的类似方案 https://github.com/povsister/v2ray-core

给你参考下我这正确配置的情况

curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://google.com

* Host google.com:443 was resolved.
* IPv6: (none)
* IPv4: 172.217.174.110
* Trying 172.217.174.110:443...
* Connected to google.com (172.217.174.110) port 443

DNS Lookup Time: 0.004620
Connect Time: 0.006571
Pre-transfer Time: 0.328742
Start Transfer Time: 0.416287
Total Time: 0.428822

t/1039732

你进 116.226 的竞技场了。无解，安分一阵子重新拨号看能不能把你提出来吧。
另外你这个“玩了几天 PT”，上传量多少啊？我一周 200G PT ，这已经一年多了都没事。