при редиректе добавляется порт 80

Nginx reverse-proxy для Bitrix VM

Введение

В данной статье я расскажу про опыт настройки Nginx в качестве прокси-сервера для сервера с bitrixVM. При типовой настройке сервера с bitrix и последующего конфигурирования Nginx в качестве прокси для него, где, казалось бы, все параметры типовые и нужно ли лишь минимально настроить proxy_pass до нужного адреса, часто могут возникать ошибки, которые всплывают в процессе эксплуатации.

Проблема подстановки 80 или 443 порта в URL

А в используемом сайте по пути, например, /etc/nginx/bx/site_enabled/bx_ext_test.example.org.conf заменить конфигурацию по умолчанию:

Таким образом, при работе сайта по https или http, всегда будет подставляться корректный порт в зависимости от используемого протокола.

По сути будет выполнено тоже самое, что и описанное ранее выше, только средствами PHP, и Apache будет понимать, что сайт работает через https.

Директива proxy_redirect заменит любой запрос заголовка location, который матчится с регуляркой при наличии 443 порта, на корректную схему уже с https. Более подробно в документации Nginx.

400 Bad Request, The plain HTTP request was sent to HTTPS port

Не совсем понятная на первый взгляд ошибка. При перенаправлении с http на https на вышестоящем Nginx proxy и обращении к имени сайта https://domain.ru/bitrix без слэша в конце, в URL подставлялся 443 порт и протокол менялся на http.

Проблема ошибки 400 Bad Request, The plain HTTP request was sent to HTTPS port заключается в модуле mod_dir у httpd. При настройке редиректа на вышестоящим прокси-сервере и открытии адреса вида domain.ru/bitrix без закрывающего слеша в конце получается проблема, когда domain.ru/bitrix – это директория. А для директорий требуется закрывающий слеш в конце. Т.е. если в Nginx даже указать proxy_set_header HTTPS YES, то для данного URL с директорией это не сработает, а потому нужно явно указать в httpd, что сайт работает по https, т.е. прописать схему в конфиг нужного virtualhost.

Проксирование websockets для Push&Pull

Ещё одна известная ошибка, которая возникает при работе сайта на битриксе через прокси – это не работает модуль Push&Pull. Точнее, не работает проверка системы, хотя казалось бы, что всё настроено: из menu.sh bx-push-server 2.0 установлен корректно штатными средствами, redis запущен, в логах ошибок нет. Но на сайте может быть красная полоса “Отсутствует соединение с сервером” и проваливается проверка системы, если обращаться через прокси-сервер.

Проблема в том, что Push server работает через wss, т.е. вебсокеты, а для этого со стороны прокси сервера необходимо проксировать дополнительные заголовки до backend, указывая явно, что клиент может сменить протокол на wss. “Upgrade” и “Connection” не передаются от клиента к проксируемому серверу, поэтому, для того чтобы проксируемый сервер узнал о намерении клиента сменить протокол на WebSocket, эти заголовки следует передать явно.

Для реализации необходимо на прокси-сервере добавить отдельный location:

А в http секции должна быть конструкция из map, определяющая значение вышеописанных переменных:

Настройка basic auth

При настройке http-авторизации на прокси-сервере с Nginx может случиться проблема с авторизацией на сайте с битрикс.

Пример следующий: на стороне Nginx basic auth успешно проходит после ввода верного логина\пароля, и пускает пользователя дальше на проксируемый ресурс. Но битрикс почему-то принимает логин и пароль от basic auth в свою веб-форму авторизации и выдает ошибку “неверный логин или пароль”. Данная проблема по началу может смутить, т.к. на первый взгляд нет никакой связи между файлом для basic auth, созданным через htpasswd, и веб-формы авторизации сайта.

В переменную REMOTE_USER добавляется значение из HTTP-заголовка HTTP:Authorization, в котором содержится логин\пароль для basic auth. А дальше битрикс пробует авторизовать пользователя уже в своей форме на основе REMOTE_USER, делается это через код.

На сайте битры об этом написано и там даже предлагаются различные решения – правки для кода. Но вся проблема в том, что это нарушение исходной целостности кодовой базы и проблема решается куда проще двумя иными способами:

Итоговый пример конфигурационного файла

Ниже приведен пример конфигурационного файла nginx proxy для сервера с битрикс:

Заключение

В статье рассмотрел основные проблемы, которые приходилось встречать и решать самостоятельно. В рунете по той или иной проблеме есть много советов, но всё хаотично разбросано и не всегда есть объяснения, как работает и как решить тот или иной вопрос. Поэтому если сделать всё по моей статье в комплексе, то ошибок возникать не должно.

Источник

Изменение протокола при редиректе на https (nginx/BitrixVM 5.1.3)

в чем может быть дело?

Достаточно создать файл:
/home/bitrix/www/.htsecure

Даже скажу чуть больше. Ошибка 400 возникает (по крайней мере у нас) когда вы пытаетесь обратиться с портом 443 по протоколу httP или по порту 80 с httPS.
У вас даже в Location: http://test.com:443/xyz/ прописано

только приводит к принудительному редиректу на ssl схему
if (-f /home/bitrix/www/.htsecure) < rewrite ^(.*)$ https://$host$1 permanent; >

то окружение делает редирект на адрес: http://test.com:443/xyz/

и в конечном итоге получаем ответ от сервера

точно знаю что на это влияет

проблема в том, что

не у меня прописано, а стандартная конфигурация битрикса:

Про htsecure Дмитрий Бирюков все правильно написал, 301 лучше.

на текущий момент проблема решена принудительным добавлением слэша, но это костыль, на мой взгляд.

но в вашем случае (без или с :80) будет происходить следующее

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

к сожалению на данный момент нет времени углубится снова в проблему, точно знаю что виной всему апач

Источник

Решение проблемы с появлением 8080 порта в ISP manager (настройка редиректа на 80 порт)

Сегодня столкнулся с проблемой — обнаружилось, что по ошибке старого системного администратора, в одном очень редком случае у нас происходил редирект с обычного 80 порта на порт 8080.

Из-за этого в индекс яндекса попала целая куча страниц, имеющих адрес example.com:8080, потому что проблема существовала уже 3 года, а заметили ее только сейчас.

Проблема усугублялась тем, что сервер конфигурировался автоматически с помощью ISP manager, что привело к тому, что сайты были доступны как по адресу example.com, так и по example.com:8080, и с учетом того, что к серверу было привязано 5 ip-адресов и на нем крутилось около 20 сайтов, переконфигурировать все вручную чтобы сконфигурировать правильным способом апач и nginx (сделать, чтобы апач слушал только 127.0.0.1 и чтобы они висели на одном порту с nginx, а внешние адреса слушал только nginx) не представлялось возможным. Проблеме потенциально подвержены все сайты, которые пользуются ISP manager, поэтому я считаю ее достаточно актуальной, и решил опубликовтаь свое решение, чтобы все тоже проверили и исправили, если надо.

Соответственно стояла задача — «малой кровью» сделать:
1. чтобы сайт example.com корректно работал, но не открывался по адресу example.com:8080
2. чтобы с порта 8080 для одного определенного сайта шел редирект на 80 порт, чтобы сохранить работоспособность страниц, попавших в выдачу яндекса.

Перейти сразу к ответу, без предыстории
Беглое гугление не показало ничего хорошего, большинство способов были аналогичны способу с iptables, предложенному тут:

Проблема в том, что этот способ не работает — dmesg выдает

После небольшого гугления нашел вариант в списке рассылки nginx-ru:
www.lexa.ru/nginx-ru/msg21134.html
Вариант был такой — перевесить в apache.conf мой сайт с моего ip 11.22.33.44:8080 на 127.0.0.1:8080, в nginx.conf соответсвенно прописать proxy_pass 127.0.0.1:8080 вместо 11.22.33.44:8080 для моего сайта, и потом добавить в конфиг nginx новый сервер

Вариант в принципе был похож на правду, но была одна проблема — апач упорно слушал порт 11.22.33.44:8080, и соответсвенно не давал nginx-у начать его слушать.

Тут меня осенило — можно просто взять, и реализовать такой же редирект, но средствами apache а не nginx.

Просто берем и добавляем в apache2.conf соответствующий VirtualHost:

Попробовал — и вуаля, все заработало!

Решение проблемы

Таким образом, решение проблемы «как сделать редирект с 8080 порта на 80«, при условии что у вас стоит debian, nginx, apache и все это настроено isp-менеджером для сайта example.com с ip 11.22.33.44, состоит из четырех простых шагов:
1. В конфиге Apache (/etc/apache2/apache2.conf) меняем все вхождения
на

2. Добавляем в конфиг Apache (/etc/apache2/apache2.conf) новый VirtualHost с редиректом:

3. В конфиге nginx (/etc/nginx/nginx.conf) меняем все вхождения

4. перезапускаем apache, перезапускаем nginx

Источник

Ошибочный редирект с https на http://$host:443

Ошибка неверного порта при отдельных переходах по страницам характерна не только для Виртуальной Машины, а и многих самостоятельных конфигураций с Nginx. Однако, данная ошибка присутствует во всех VM Bitrix на протяжении последних лет.

Как проявляется баг?

Простым взглядом на строки легко понять, что проблема кроется в том, что страница «находящаяся» на https пытается быть открытой по протоколу http или в «иную сторону».

Зачастую найти точки входа ботов на ошибочные страницы довольно сложно. Это могут быть результаты поиска, переход после авторизации, результаты форм и что угодно еще. Радует то, что по-большому счету искать причину и не нужно. Главное устранить эти «нелогичные» редиректы на уровне сервера.

Отдельным случаем проявления данной проблемы является открытие страницы с ошибкой 400. На данной странице красуется сообщение: The plain HTTP request was sent to HTTPS port

Правим конфиги «Виртуалки»

Если у вас на виртуальной машине работает один сайт, то понадобится найти файл конфига Апапч:

и над ServerAdmin [email protected] вставляем

При многосайтовой конфигурация виртуалки делаем тоже самое, но в файле нужного сайта bx_ext_YOUR_SITE.conf

Альтернативный способ

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

Добавляем error_page 497 https://$host$request_uri;. Получим нечто похожее на:

Проблема должна исчезнуть. Если вам известны иные методы напишите нам в комментариях.

Решение наверняка 🙂

Добавляем return 301 https:/YourDomain.com$request_uri;. Получим нечто похожее на:

Источник

Закрыть 80 порт и сделать редирект с 80 на 443

Товарищи подскажите, как закрыть 80 порт. И сделать редирект с 80 на 443 apache 2.0 на сервере.
Спасибо.
Мануал с вики апача мне не смог помочь..

Помощь в написании контрольных, курсовых и дипломных работ здесь.

443 порт socks
Курсач реализация клиента-сервера socks5 Клиент подключается к серверу и так происходит загрузка.

Vpn через 443 порт
Доброго времени суток. Купил себе одноплатный компьютер cubietruck для домашнего сервера + поднять.

Правильный редирект 443 порта в iptables
Как правильно реализовать перенаправление портов исходящего трафика в iptables? Из за блокировки.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Установка сертификата SSL порт 443
Всем привет! На одном сервере два сайта, один из них с установленным сертификатом ssl, пытаюсь.

Как залогиниваться через 443 порт?
При проверке сайта OWASP(ом) поставлена ошибка, что залогинивание идет через 80, а не через 443.

Как включить порт 443(https)
Доброе время суток! надеюсь, по адресу пишу! на работе в бухгалтерии и используется программный.

Работа через 443 порт (SSL)
собственно вопрос по поводу работы через 443 порт. у меня есть код, который отлично отрабатывает по.

Источник