把 OpenClaw Gateway 放在 Linux 云 VPS 上、把 Ollama 留在家里或内网，是常见的成本与隐私折中：公网入口与通道回调走 VPS，算力与模型文件留在可控边界内。真正麻烦的是「谁连谁」——TLS 在哪一层终止、反代上游写的是 127.0.0.1 还是 10.x、systemd 环境里是否继承了会把本地地址也送进公司 HTTP 代理的变量，以及 SSH 隧道断开后为何只剩 502。下文按可复现顺序给出矩阵与命令，并把 502 与读超时拆成三层自查，避免一上来就改模型参数。
拓扑与目标：三种上游各写哪一段
同机部署时 Gateway 指向 http://127.0.0.1:11434 即可；内网部署写固定 RFC1918 地址并确保 VPS 到该网段有路由或专线；本机在家、VPS 在云上时，通常用 SSH 远程转发（-R） 从家用机连出，把 Ollama 映射到 VPS 的环回口，再让 Gateway 只认 127.0.0.1，避免把未监听的公网端口暴露出去。无论哪种，建议把「公网 TLS」「Gateway 进程」「Ollama HTTP」三层拆开命名，排障时按层对照日志时间线。延伸阅读：2026年OpenClaw部署路径对比：Fly.io容器平台与普通Linux云VPS直装在持久卷、公网入口、通道Webhook回调与健康检查上的决策矩阵与可复现排障FAQ。
HTTP(S)_PROXY 与 NO_PROXY 决策矩阵
若机器配置了全局出站代理，未正确设置 NO_PROXY 时，Gateway 或 sidecar 可能把对 127.0.0.1、10.0.0.0/8 的请求也送进代理，表现为偶发超时或「连接被拒绝却走了代理 CONNECT」。把内网与环回写进 NO_PROXY（含大小写变体与 CIDR 写法）并在 systemd drop-in 中显式覆盖，通常比注释掉整段代理更安全。
| 场景 | 建议 NO_PROXY 片段 | 典型症状 |
|---|---|---|
| Gateway → 本机 Ollama | 127.0.0.1,localhost,::1 |
首 token 慢、CONNECT 失败日志 |
| Gateway → 内网 Ollama | 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal |
仅部分时段失败（PAC 切换） |
| SSH 隧道环回上游 | 同上并固定 OLLAMA_HOST 仅监听 127.0.0.1 |
隧道断后立刻 502 |
curl -sS http://127.0.0.1:11434/api/tags 验证上游可达，再测经反代的 HTTPS 路径，最后才回到 Gateway 业务日志；否则容易把「反代没配好」误判成「模型太大」。
可复现：SSH 把本机 Ollama 接到 VPS 环回
在家用机执行反向或本地转发任选其一，核心是 VPS 上始终有一个稳定的 127.0.0.1 端口 指向家中的 11434。下面示例为在家发起、把 VPS 的 18080 转到本机 Ollama（请替换用户与主机名）：
# 在家用机执行：让 VPS 的 127.0.0.1:18080 转发到本机 Ollama ssh -N -T -R 127.0.0.1:18080:127.0.0.1:11434 user@vps-public-ip # 在 VPS 上验证（应返回 JSON 列表） curl -sS http://127.0.0.1:18080/api/tags
生产环境请改用 autossh 或 systemd 单元托管重连，并把监听地址限制在环回或内网接口，配合防火墙避免把转发口误绑到 0.0.0.0 对公网开放。多通道场景下的分层排障思路可与 2026 OpenClaw 接入 WhatsApp（Linux 云 VPS）：二维码配对、会话持久化与多通道并存——可复现步骤与断连/429 分层排障 FAQ 对照阅读。
TLS 终止拆分：反代与 Gateway 各管一段
常见做法是 Caddy / Nginx 在 443 终止 TLS，反代到本机 Gateway 的 HTTP 端口；Gateway 再以明文 HTTP 访问 Ollama。注意证书域名与 Host 头、WebSocket 升级头是否透传；若你把 TLS 一直延伸到 Ollama，则需要额外信任链与端口规划，和「仅内网明文」模型不同。反代返回 502 时，优先看 error log 里的 upstream connect failed 还是 read timeout，两者对应修防火墙与修上游监听。
proxy_read_timeout 过短会在首包未出前断开；与「模型算不动」区分的方法是直接 curl 上游并观察是否稳定输出 token。
502 与读超时：分层 FAQ
| 现象 | 优先检查 | 处置要点 |
|---|---|---|
| 瞬时 502，SSH 断后必现 | 隧道进程、ss -lntp 监听 |
自动重连、限制绑定地址 |
| 偶发超时、日志出现 CONNECT | env | grep -i proxy、systemd drop-in |
补齐 NO_PROXY，避免环回走代理 |
| HTTPS 正常、直连 Ollama 失败 | 上游 URL 是否写成 https | 内网明文用 http，或显式配置 mTLS |
把每一层用同一请求 ID 串起来：反代 access log、Gateway 日志、Ollama 推理日志的时间戳对齐后，绝大多数「神秘 502」都会落在监听消失或代理误伤两类。固定版本镜像与只读发布通道，能把回归面缩到配置 diff 而不是整盘猜测。
在本机或边缘节点跑 Ollama，Mac mini 更省心
若你希望模型与向量数据尽量留在自有硬件，却又不想维护高功耗塔式机，一台常驻的 Mac mini 往往是更安静的底座：Apple Silicon 统一内存让 7B～13B 级模型的本机推断在同功耗预算下更从容，macOS 原生 Unix 栈与 Homebrew 生态也让 Ollama、Docker 与 SSH 隧道脚本可以长期稳定运行，而不必在 Windows 上叠加 WSL 与驱动变量。
从总拥有成本看，M 系列 Mac mini 待机功耗极低，适合 7×24 作为家庭内网的上游节点；Gatekeeper、SIP 与系统更新节奏清晰，也比拼凑 Linux 桌面更省心。若你还需要在云上完成签名、CI 或与公网通道对接，可把「重算力」留在本地 Mac、「轻编排」放在 VPS，边界更清晰。
如果你正在规划把本地 AI 与云端编排结合起来，VPSSpark 云端 Mac mini M4 是目前性价比很高的起点——立即了解套餐方案，让开发与推断环境都更可控。