GL-MT3600BE passwall 开了，Google 不通，竟是内存 OOM
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 内存里。 ...