网络

最近买了台 DMIT LAX Pro，前前后后折腾了一阵，最后把它做成了家里网络的美国入口。 买 VPS 很容易陷进参数表。几核 CPU、多少内存、硬盘多大、端口标多少 Gbps，看起来都很直观。可一台放在洛杉矶、主要从国内连接的 VPS，最影响体验的通常是跨境线路。机器配置再高，晚高峰一路绕、丢包、抖动，代理照样难用。 我买 DMIT，主要也是为了这条线路。 为什么是 DMIT LAX Pro DMIT 的产品分成三类：Premium，也就是大家常说的 Pro；Eyeball，也就是 EB；以及面向国际网络的 Tier 1。按这份整理，Pro 的重点是 CN2 GIA 和中国大陆方向的线路质量，EB 更偏价格与体验的平衡，Tier 1 则没有专门为大陆访问做优化。 我需要的是一台长期在线的美国节点，平时从国内连接，同时还要承载一些 API 和轻量服务。香港和东京离得更近，但出口位置不在美国；普通洛杉矶 VPS 能给美国 IP，回国线路又经常要碰运气。LAX Pro 刚好卡在中间，保留美国西海岸的位置，又把中国方向的路由放在更高优先级。 这类机器卖得贵，钱主要花在线路上。要是只跑定时任务、离线下载或者面向海外用户的小网站，便宜的 Tier 1 机器更合适。我的流量需要每天从国内进来，线路稳定比多两核 CPU 更有用。 下面是这台机器跑 Bench、回程路由、IP 和国内延迟测试时的结果： 入口用的是 VLESS + TCP + REALITY + Vision 代理入口跑在 Xray 上，客户端协议是： VLESS + TCP + REALITY + xtls-rprx-vision 一个 443 同时跑代理和 Web 服务 这台机器除了代理，还跑着一个对外的 Web 服务。两个入口都想用标准的 HTTPS 端口，我没有给 Xray 再开一个显眼的公网端口，而是在最前面放了 Nginx stream。 ...

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 内存里。 ...