2026 OpenClaw на Linux VPS в облаке: Ollama во внутренней сети или локально — upstream Gateway, разделение TLS, SSH-туннель и матрица NO_PROXY; воспроизводимые шаги и FAQ по 502 и таймаутам

Размещать OpenClaw Gateway на недорогом Linux VPS, а Ollama оставить дома или во внутреннем сегменте — типичный компромисс между стоимостью и приватностью: публичный вход и webhook каналов остаются в облаке, вычисления и файлы моделей — в зоне, которую вы контролируете. Сложность почти всегда в том, кто к кому подключается: на каком уровне завершается TLS, в upstream у reverse proxy указан 127.0.0.1 или адрес 10.x, унаследовал ли процесс systemd переменные, из-за которых запросы к локальному адресу уходят в корпоративный HTTP-прокси, и почему после обрыва SSH остаётся только 502. Ниже — воспроизводимая матрица и команды, а также три уровня самопроверки для 502 и таймаутов чтения, чтобы не списывать всё на «слишком большую модель». Дополнительно о выборе платформы развёртывания: 2026: OpenClaw — Fly.io против обычного Linux VPS: постоянные тома, публичный вход, webhook каналов и health checks (матрица + FAQ).

Топология и цель: три варианта upstream

При colocation Gateway и Ollama на одной машине достаточно http://127.0.0.1:11434. Для сегмента RFC1918 задайте фиксированный внутренний адрес и маршрут или выделенный канал с VPS. Если Ollama дома, а VPS в облаке, чаще всего используют обратную SSH-пересылку (-R): домашний хост инициирует сессию и пробрасывает порт Ollama на loopback VPS, после чего Gateway обращается только к 127.0.0.1, не открывая пустой порт в интернет. Во всех схемах полезно явно разделить три имени: «публичный TLS», «процесс Gateway» и «HTTP Ollama» — по журналам проще сопоставить временную шкалу инцидента.

Отдельно зафиксируйте в runbook, какой компонент отвечает за обновление DNS для внутренних имён и кто перезапускает туннель при смене IP домашнего провайдера: иначе каждый инцидент превращается в спор между «сетью» и «приложением». Для смешанных сред с корпоративным PAC-файлом полезно иметь минимальный набор curl-проверок без GUI-браузера, чтобы ночные job не зависели от политики рабочей станции оператора.

HTTP(S)_PROXY и матрица NO_PROXY

Если на машине задан глобальный исходящий прокси, без корректного NO_PROXY Gateway или sidecar могут отправлять и запросы к 127.0.0.1 и к 10.0.0.0/8 через прокси: это даёт редкие таймауты или «отказ в соединении», но в логах виден CONNECT. Включите loopback и внутренние префиксы в NO_PROXY (учитывайте регистр и CIDR), лучше через systemd drop-in, чем отключать прокси целиком для сервиса.

Воспроизведение: SSH подключает домашний Ollama к loopback VPS

На домашней стороне можно выбрать локальную или удалённую пересылку; важно, чтобы на VPS стабильно слушался порт 127.0.0.1, указывающий на домашний 11434. Пример: с домашней машины пробросить порт 18080 на VPS (подставьте пользователя и хост):

# На домашней машине: 127.0.0.1:18080 на VPS → локальный 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

В проде замените одноразовый ssh на autossh или unit systemd с автопереподключением, ограничьте bind интерфейсом loopback и firewall, чтобы случайно не опубликовать пересылку на 0.0.0.0. Идею поуровневого разбора при нескольких каналах можно сопоставить с 2026: OpenClaw и WhatsApp на Linux VPS в облаке: сопряжение по QR, сохранение сессии и несколько каналов — воспроизводимые шаги и FAQ по обрывам и 429.

Разделение TLS: reverse proxy и Gateway

Обычно Caddy или Nginx завершает TLS на 443 и проксирует на HTTP-порт Gateway; Gateway затем ходит в Ollama по обычному HTTP. Проверьте совпадение имени в сертификате, заголовок Host и прохождение апгрейда WebSocket. Если TLS тянуть до самого Ollama, понадобятся отдельная цепочка доверия и порты — это другая модель, чем «прозрачная внутренняя сеть». При 502 в error log сначала отличайте upstream connect failed от read timeout: первое чаще про firewall и listen, второе — про таймауты прокси и долгий стриминг.

502 и таймаут чтения: многоуровневый FAQ

Если 502 появляется только на длинных запросах, а короткий /api/tags всегда успешен, сравните лимиты тела ответа и буферизации у reverse proxy с тем, как Gateway стримит чанки: иногда помогает отключение буферизации для конкретного location или увеличение окна чтения только для маршрута к модели, не размывая глобальные таймауты для health check.

Сведите по одному request id access log reverse proxy, логи Gateway и Ollama: после выравнивания меток времени большинство «непонятных» 502 сводится к исчезнувшему listen или к прокси, перехватывающему локальные адреса. Зафиксированные образы и канал выката только с диффом конфигурации сильно сужают поверхность регрессий.