618 买了台 GL-MT3600BE，折腾了大半天，最后发现根因离谱到我自己都没想到。
毛病是这样的：路由器上配置了 passwall2 做代理，国内的网站都能开，百度、B 站、各种 App 都顺，唯独 Google、YouTube 这些死活打不开。你要知道这个现象有多误导，因为 passwall 面板里节点状态是绿的，延迟测速都正常，点"测试节点"也能通。所有迹象都告诉你"代理是好的"，可就是访问不了 Google。
我一开始的判断全错了。先怀疑是节点挂了，换了好几个香港、日本的节点，没用；又怀疑是 DNS 污染，Google 被解析到了假 IP，结果 dig 一看解析也对；再怀疑是分流规则把 Google 误判成国内直连了，翻了一遍规则，也没问题。每个方向看起来都合理，每个方向都白跑。
转机是我去翻系统日志。一条命令：
logread | grep -i "out of memory"
刷出来一屏 Out of memory: Killed process xray。我当时就愣住了。原来根本不是代理的问题，是 xray 被系统当场杀了。
想明白之后整条链路就通了。passwall 这种代理不是一个进程在跑，它会同时拉起好几个东西：一个 sing-box 跑你选的节点，一个 xray 做分流。xray 启动时要把 geoip.dat 和 geosite.dat 加载进内存，用来判断哪些流量走代理、哪些直连。这俩文件一个 20MB，一个 10MB，加载那一下内存峰值能冲到一百多 MB。
再叠上 GL 固件本身那一堆守护进程，tailscaled、nginx、各种 gl-* 服务，这台机器当时内存本来就紧。结果就是 xray 每次一启动，内存一冲高，立刻被内核的 OOM killer 干掉。
xray 一死，passwall 检测到核心没了，会退回到"非代理模式"，也就是把所有流量都放直连。这下全说通了：国内站本来就该直连，所以百度照常；Google 直连必然撞墙，所以打不开；节点测速是单独发起的，不经过那个已经死掉的分流核心，所以面板里看着一切正常。
一个被 OOM 悄悄杀死的进程，伪装成了"代理时好时坏"的玄学问题。结果根子就在那原生的 512MB 内存里。
修起来反而简单。我先把 Tailscale 关了，腾出六十多 MB；再装 zram-swap，在内存里压一块 swap 出来兜底。
opkg install zram-swap
/etc/init.d/zram enable
这俩做完，xray 就稳稳活住了，Google、YouTube 立马恢复。后来我嫌每次都要这么精打细算地省内存太累，干脆把这台直接升到了 2G，从此再没纠结过内存。
这趟下来最值钱的一条经验：小内存路由器上跑 passwall 这类多进程代理，真得给内存留余量。geoip/geosite 加载时的峰值最容易爆。实在加不了内存，zram-swap 是个便宜好用的缓冲；能加内存就别省那点钱。我在小黄鱼找人升到 2G 之后，内存焦虑直接消失。
当然，厂家也别太吝啬。现在内存溢价是厉害，但 512MB 真装不了几个插件。