背景

前面两篇记录了怎么用 iWAN 隧道 + 自建 VPS/L2TP 做跨境出口。那两篇解决的是”整条账号的所有流量走哪个出口”，但实际用下来需求更细：YouTube 这类大流量留在默认出口，Claude/ChatGPT 这类走专门的美国出口，Google 其它服务和默认出口一致——这就不是”按账号分流”能解决的了，得精确到”按域名分流”。

这篇记录这个过程踩的坑，比预想的深得多：从一个看起来人畜无害的 Fake-IP 怪现象，一路挖到 DoH 兼容性、陈年连接跟踪记录，最后还撞上了 IPv6 双栈这个完全没预料到的硬骨头。

背景

手上的 SD-WAN iWAN 客户端(sdwand)官方只给了裸机部署方式：一个二进制+ 一份配置文件，配 systemd 拉起来就行。但我想把它塞进 MikroTik RouterOS的 /container 里跑——路由器本身就是流量的枢纽，隧道建在路由器自己的容器环境里，比额外接一台旁路设备更省事。

这个想法本身没问题，sdwand 装进 Debian 容器里确实能跑起来。真正麻烦的是后面那步：怎么让局域网里其他设备的流量，经过容器里的这条隧道出网。容器有自己独立的网络命名空间，RouterOS 的主路由表根本看不到容器内部那张隧道网卡，这中间要打通的环节比想象中多得多，而且一个坑套着下一个坑，最后那个根因差点让我以为是硬件问题。

背景

手上有一条按月付费的 Panabit iWAN 隧道服务，跨境访问是没问题的，但出口 IP是服务商统一分配的默认出口，没法控制。想要的效果很简单：跨境这段继续走
已经付费的 iWAN 隧道，但最终出网的 IP 换成我自己买的那台 VPS。

看起来是个很直觉的需求，但实际折腾下来，光是搞清楚”该在哪一端加配置”就走了不少弯路，中间也踩了几个挺隐蔽的坑，记录一下。

最近给一台 2019 款 Mac Pro（MacPro7,1）安装 macOS 更新时，连续遇到了同一个严重问题：更新进行到重启阶段后无法正常完成，机身状态指示灯橙色闪烁，最后只能拔掉电源才能重新开机。系统虽然还能回到桌面，但版本没有更新成功。

这不是一次普通的下载失败。系统日志最终证明，真正失败的是 Apple T2 安全芯片内部的 BridgeOS 固件升级。通过另一台 Mac 执行一次不抹除数据的 DFU Revive 后，T2 固件成功更新，随后 macOS 也顺利完成升级。

引言：代码已经不再是瓶颈

AI已经让软件代码的生产速度发生了数量级变化，但围绕代码生产建立起来的组织流程，并没有以相同速度改变。

今天回来,要帮同学远程运维一下之前的服务器(他忘记续费了),忽然发现运维脚本执行后没反应(往常1分钟一台跑完的).

手上有两个云盘：115 网盘存了大量影视资源，123 云盘有不错的带宽和直链能力。日常需求很简单——让 媒体库的文件,可以通过 115 和 123 的通道播放和下载。

极致优化：如何将 128k 上下文的显存占用从 87GB 降至 66GB？

在上一篇博文中，我们展示了双 3090/四 3090 环境下部署 Qwen3-30B 的基础性能。今天，通过引入 OLLAMA_KV_CACHE_TYPE=q8_0，我们将这项测试推向了新的巅峰：在不损失响应速度的前提下，显存占用降低了 **24%**。

追求极致：当 4 张 3090 遇上 Qwen3 MoE

在本地部署大模型的道路上，显存容量决定了“深度”，而架构设计决定了“速度”。最近我将本地环境升级到了 4x RTX 3090 (96GB VRAM)，并部署了 Qwen3-Coder-30B-A3B-Instruct-Q8。以下是针对 32k 到 128k 上下文的真实性能压测报告。

在 AI 编程工具（如 Trae, Cursor）百家争鸣的时代，拥有一套高性能的本地大模型环境，不仅能保护代码私密性，更能通过极低的延迟提升“人机合一”的快感。本文记录了在 NVIDIA RTX 3090（多卡）环境下，利用 Ollama 部署 Qwen3-Coder-30B (MoE) 并进行深度调优的全过程。