Андрей Николаев

Не занимайтесь ерундой - это все сложнее чем вам бы хотелось.
Самый простой вариант - проксируйте как есть на bitrix env и пусть он занимается сертификатами и всем остальным.

1. Надо ли пробрасывать с внешнего IP порты 1137, 1139? И куда пробрасывать на Nginx Revers Proxy или напрямую на Б24? (Пробовал и так и так, ничего не дало, никаких изменений).
2. Если я пробрасываю порты 1137, 1139 на Nginx Revers Proxy надо ли мне их как-то в конфиге nginx дальше проксировать на ВМ Б24? Или пробросить на ВМ Б24 через iptables DNAT'ом?

Эти порты, ровно как и порты 80* и 90* проксировать НЕ нужно.
Да, это было необходимо ранее, когда использовался nginx-push-stream-module, но он устарел еще на версии битрикс эдак 18-й, а с версии 22 уже требуется Bitrix NodeJS v2 - да-да именно второй (был еще и первый как промежуточный).
Он работает на двух технологиях - long polling и websocket, но главное - он работает по потому же порту что и HTTP/HTTPS, т.е. проксировать достаточно только их.

3. Сертификат SSL у меня установлен на Nginx Revers Proxy (что видно из конфига), нужно ли при этом ещё один SSL сертификат устанавливать для ВМ Б24?

Если вы хотите чтобы это корректно работало, то вам необходмо будет ЛИБО прокидывать на 443 -> 443 и безоговорочно доверять всему и ловить ошибки самого битрикса, либо дублировать сертификат на локальную машинку.

Вот только этот сертификат придется устанавливать еще на:
- nginx
- apache (http-scale сервис)
- push-service

И если с первыми двумя еще как-то нормально, то по последнему документации вы не найдете.
В противном случае вы можете получить интересные ошибки когда часть сообщений отправляемых в пул не будет попадать в пул из-за того что битрикс не будет доверять сам себе.
Вы же не полезете в ядро выключать проверку сертификатов?

Я попробую поискать наш reverse-proxy конфиг который мы используем для проброса.

Пытаюсь настроить так, чтобы в пуше не было текста сообщения, а было сообщение вида "У вас новое сообщение!". Подскажите, пожалуйста, куда копать?

В ядро модуля push'n'pull, но это противоречит смыслу этого модуля и всей подсистемы (прощай телефония, интерактив и т.п.).

nginx тут вам особо не поможет: пересматривайте подключение скриптов на странице.
ЕСЛИ скрипты подключены по относительному пути и начинаются с символа слеш (/src.js), то такие пути будут искаться от корня сайта, а не вашей директории.
Конечно можно попробовать использовать тег base, но он тут вряд ли поможет.

Не туда смотрите: сначала в консоль браузера, затем в случае nodejs (а у вас именно такой случай) - /var/log/push-server/ и там уже смотрите логи :)

Я так понимаю, задача стоит следующая: в зависимости от доступа пользователя, давать скачивать ему файл. Т.е. если доступ есть он может скачать файл, если нет - не может, при этом если права отбирают, то файл он больше скачать не может.

Попробуйте - X-Accel

This allows you to handle authentication, logging or whatever else you please in your backend and then have NGINX handle serving the contents from redirected location to the end user, thus freeing up the backend to handle other requests. This feature is commonly known as X-Sendfile.

Доверять ключу вы можете зайдя на https://mysite.dev и добавив его в доверенные (Если вы открываете сайт по https и хром не выдает предупреждений, значит сертификат доверенный). Однако хром будет помечать его красным цветом - так как вы его сами себе выдали.

Пробовали:

proxy_pass http://127.0.0.1:6789;

if ( $server ~ 2 ) {
	proxy_pass http://122.22.22:6789;
}

Может это внутреннее? Как-бы 503 - это Service Unaviable, а вы вместо отдачи на /maintrance.html отправляете.
А он уже 200 отдает.

Попробуйте удалить:

location = /maintrance.html {
return 200;
}

Будет ли подобный результат ?