2026 OpenClaw Linux クラウドVPSと社内／ローカルOllama接続：Gateway上流、TLS終端分離、SSHトンネルとNO_PROXYマトリクス——再現手順と502／タイムアウト層別排障FAQ

推論を社内PCや自宅のOllamaに置き、常時接続のOpenClawゲートウェイだけLinuxクラウドVPSに載せる構成はコストと秘密保持のバランスが良い一方、設定ミスがログに散らばります。切り分けの核は「ゲートウェイが参照する上流URL」「TLSをどこで終えるか」「HTTP(S)_PROXY越しに127.0.0.1へ行っていないか」「SSHトンネルの待受と宛先の取り違え」の四点に収束しがちです。

構成の骨子：VPSは入口、Ollamaは信頼境界の内側

外向きは443でnginxやCaddyがTLS終端し、ループバックのゲートウェイへプロキシします。Ollamaは原則としてインターネットに晒さず、http://127.0.0.1:11434のようなループバック、社内DNS名、またはSSH -RでVPS上に出したローカル待受だけを上流に書きます。公式の環境変数名や既定ポートはリリースで変わるので、導入時に必ずドキュメントへ当てます。

SSHトンネル再現（例：自宅OllamaをVPSの11434に露出）

自宅側でOllamaが動いている前提で、手元からVPSへリモートフォワードします。GatewayPortsや社内FWの穴あけが必要ならインフラ側と先に合意します。

ssh -N -R 127.0.0.1:11434:127.0.0.1:11434 [email protected]

VPS上のゲートウェイ設定では上流をhttp://127.0.0.1:11434に揃え、systemdならAfter=network-online.targetとトンネルユニットの順序依存を入れて起動競合を避けます。接続テストはゲートウェイと同じユーザーでcurl -sS http://127.0.0.1:11434/api/tagsを叩き、ここで失敗するならアプリ以前の問題です。

NO_PROXYマトリクス（よく落ちる組み合わせ）

企業プロキシやHTTP_PROXYを有効にしたまま127.0.0.1へ流すと、タイムアウトや謎502の温床になります。典型パターンを表にまとめます。systemdユニットならEnvironment=NO_PROXY=127.0.0.1,localhostを明示し、シェルログイン用の~/.bashrcだけに依存しないようにすると再現性が上がります。

502とタイムアウトの層別FAQ

層1（TLS入口）。証明書名不一致やリバプロのproxy_pass末尾スラッシュ違いは即502。まずリバプロのerrorログとcurl -v https://公開名で切ります。層2（ゲートウェイ→Ollama）。上流URLがコンテナ内の127.0.0.1を指していない、トンネル未起動、待受競合が多いです。ss -lntpで11434の所有者を確認します。層3（モデル推論）。初回ロードやVRAM不足はHTTP 502相当で返る実装もあるため、Ollama側ログと同時刻のリクエストIDを突き合わせます。

短周期で隔離・エグレス・シークレット配分を詰めるなら 2026年・短周期AIツール試行とバッチバースト：日単位クラウドMacと軽量VPS——隔離・エグレス・シークレットの意思決定マトリクスFAQ、入口とヘルスチェックの設計は 2026年、OpenClawのデプロイ経路比較：Fly.ioと汎用LinuxクラウドVPS──永続ボリューム、パブリック入口、チャネルWebhookとヘルスチェックの意思決定マトリクスと再現FAQ と併読すると早いです。