Как обеспечить работу виджета «Открытая линия» в Bitrix24, если портал закрыт для внешнего доступа?

Ситуация: есть внутренний корпоративный портал с CRM (Bitrix24) и сайт — фронт на Nuxt, бэк — Битрикс ("Управление сайтом"). На сайте установлен виджет "Открытой линии" Bitrix: скрипт подключён в nuxt.config и делает запросы к порталу. Портал недавно закрыли от внешнего доступа, из‑за чего виджет перестал работать. Пытались давать точечный доступ к скриптам, которые запрашивает виджет, но это выглядит ненадёжным (возможны проблемы после обновлений Bitrix), да и полностью выудить весь список требуемых скриптов не получилось. При этом с бэка сайта портал доступен. Кто‑то сталкивался с подобной проблемой и какие надёжные решения возможны, чтобы виджет работал при закрытом внешнем доступе к порталу?
  • 3 апреля 2026 г. 14:00
Ответы на вопрос 2
Коротко — проблема в том, что виджет подгружает скрипты и поддерживает соединение (push/pull, WebSocket/long‑poll) напрямую с адресом портала. Если портал недоступен извне, то браузер клиента не может до него дотянуться. Надёжные варианты решения:

1) Проксировать весь трафик виджета через публичный gateway (рекомендуемое)
- На публичном сервере (тот же сервер сайта или отдельный) поднять обратный прокси (nginx, haproxy, Caddy) который проксирует только нужные пути к внутреннему порталу. Браузер клиента идёт на публичный домен -> прокси пересылает запросы внутрь сети к Bitrix.
- Преимущества: не надо поддерживать список отдельных файлов, виджет всегда получает актуальные скрипты; поддерживается WebSocket/long‑poll при правильной конфигурации; вы можете ограничить доступ (IP, basic auth, rate limit) и логировать.
- Минусы: нужно обеспечить защищённый канал между публичным прокси и внутренним порталом (VPN/SSH туннель/динамическая маршрутная настройка), позаботиться о CORS/Host/сессиях.

Важно при этом:
- Проксировать не только статические js, но и push/pull эндпойнты (pull_server.php, /pub/pull.php, /bitrix/services/pull/..., /rest/..., компоненты openlines и т.д.).
- Включить поддержку WebSocket и заголовков Upgrade в прокси: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade".
- Сохранять Host/Cookie/Referer при проксировании (proxy_set_header Host $host или оригинальный host портала в зависимости от нужд).
- Ограничить доступ к прокси (по домену источника, ip сайта, Basic Auth или client cert).

Пример nginx‑блока (упрощённо):
location /improxy/ {
    proxy_pass http://internal-bitrix/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_set_header Host internal-bitrix.example.local;
    proxy_buffering off;
}
(в реальном случае используйте отдельные location для /bitrix/, /pub/, /rest/, /bitrix/services/pull.php и т.д. и корректно настраивайте host/ssl)

2) Хостить скрипты виджета локально + проксировать API/pull
- Скачиваете актуальную версию клиентского скрипта виджета и кладёте на свой сайт. Но сам скрипт всё равно делает запросы к порталу — их нужно проксировать. Это уменьшает количество внешних запросов к порталу, но при обновлении Bitrix скрипт может сломаться — придётся обновлять вручную.

3) Сделать «мост» на бэке (bridge)
- Браузер соединяется с вашим беком, бек держит соединение с внутренним порталом (через REST/websocket). Ваш бек ретранслирует сообщения между клиентом и порталом. Более сложная разработка, но полностью контролируемая и безопасная схема. Рекомендуется, если хотите кастомный UI или полноту контроля без экспонирования портала.

4) Полностью заменить виджет — собственная реализация Open Line
- Построить собственный виджет, использующий REST API портала (через бек‑мост). Это самый трудоёмкий путь, зато не зависит от внутренних реализаций Bitrix.

Практические шаги, которые советую выполнить:
1. На рабочем окружении (когда портал временно открыт или через внутренный доступ) откройте DevTools и посмотрите все сетевые запросы при загрузке виджета — какие пути, какие endpoints и какие заголовки/соединения (ws/long‑poll) он использует.
2. Настройте публичный прокси, который прозрачно проксирует соответствующие базовые пути к внутреннему порталу (не пытайтесь перечислять десятки файлов — проксируйте каталоги/эндпойнты).
3. Обеспечьте безопасный канал между публичным прокси и внутренним порталом (VPN/SSH туннель/DMZ) и ограничьте доступ к прокси.
4. Протестируйте и проверьте работу push (WebSocket/long‑poll), cookies и авторизации.

Почему не стоит давать «точечный доступ к скриптам»
- Списки файлов меняются при обновлениях Bitrix, можно пропустить новый файл и виджет перестанет работать. Гораздо безопаснее проксировать пути/эндпойнты или делать бэкенд‑мост.

Если хотите, могу:
- Посмотреть список запросов, которые делает виджет (вставьте dump из DevTools), и подготовить конкретный nginx‑конфиг/список путей для проксирования;
- Подсказать, как организовать безопасный туннель между публичным сервером и внутренним порталом.
у нас было такое же — закрыли коробку, виджет отвалился. решили через nginx reverse proxy: пропускаем только нужные директории ( <code>/upload/crm/site_button/</code> , <code>/online/</code> , <code>/bitrix/js/im/</code> плюс websocket push-сервера), остальное 403. за год ни разу не ломалось при обновлениях. <br/> <br/> ключевое тут не конкретные скрипты перечислять, а целые пути. директории стабильные между обновлениями. кста, в devtools посмотри какие ещё запросы виджет шлёт, мб <code>/rest/</code> тоже придётся открыть.
Похожие вопросы