Verification: a143cc29221c9be0

Nginx или apache для bitrix

Nginx или apache для bitrix

Содержание

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Общий обзор

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

Apache

Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.

Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.

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

Nginx

В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.

Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.

Администраторы часто выбирают Nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его и как веб-сервер, и как прокси.

Архитектура обработки соединений

Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.

Apache

Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:

  • mpm_prefork — этот модуль создает по одному процессу с одним потоком на каждый запрос. Каждый процесс может обрабатывать только одно соединение в один момент времени. Пока число запросов меньше числа процессов этот MPM работает очень быстро. Однако производительность быстро падает когда число запросов начинает превосходить число процессов, поэтому в большинстве случаев это не самый лучший выбор. Каждый процесс потребляет значительный объем RAM, поэтому этот MPM сложно поддается масштабированию. Но он может быть использован вместе с компонентами, которые не созданы для работы в многопоточной среде. Например, PHP не является потокобезопасным, поэтому этот MPM рекомендуется использовать как безопасный метод работы с mod_php.
  • mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками. Каждый поток может обрабтывать одно соединение. Потоки значительно более эффективны чем процессы, что означает что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше чем процессов это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.
  • mpm_event — этот модуль похож на mpm_worker, но оптимизрован под работу с keep-alive соединениями. Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того активное это соединение или keep-alive. Mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений. Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы. Этот модуль был отмечен как стабильный в Apache версии 2.4.

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

Nginx

Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.

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

Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла.

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

Статический и динамический контент

Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.

Apache

Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.

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

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

Nginx

Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.

Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx'у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.

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

Распределенная конфигурация против централизованной

Для администраторов одним из очевидных отличий этих двух веб-серверов является наличие у Apache возможности задавать конфигурацию на уровне директории.

Apache

Apache имеет опцию, которая позволяет включить конфигурирование на уровне директорий. Если эта опция включена, то Apache будет искать конфигурационные директивы в директориях с контентом в специальных скрытых файлах, которые называются .htaccess.

Так как такие конфигурационные файлы находятся в директриях с контентом, Apache вынужден при обработке каждого запроса проверять не содержит ли каждый компонент запрашиваемого пути файл .htaccess и исполнять директивы в найденных файлах. Это позволяет децентрализовать конфигурирование веб-сервера, что позволяет реализовать на уровне директорий модификацию URL'ов (URL rewrite), ограничения доступа, авторизацию и аутентификацию и даже политики кеширования.

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

Это дает простой способ таким приложениям как системы управления контентом (CMS) конфигурировать собственное окружение не имея доступа к конфигурационному файлу веб-сервера. Это также может быть использовано шаред хостингами, чтобы сохранить контроль над основным конфигурационным файлом и дать клиентам контроль над конфигурацией определенных директорий.

Nginx

Nginx не интерпретирует файлы .htaccess и не предоставляет механизм конфигурирования на уровне директорий за пределами основного конфигурационного файла. Этот подход может показаться менее гибким чем в случае с Apache, но он имеет свои преимущства.

Основное преимущество перед использованием .htaccess — это улучшенная производительность. Типичная установка Apache позволяет использовать файлы .htaccess в любой директории, поэтому веб-сервер при каждом запросе вынужден проверять наличие этого файла во всех родительских директориях запрошенного файла. Если найден один или более таких файлов, то все они должны быть прочитаны и интерпретированы.

Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).

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

Имейте ввиду, что вы можете отключить поддержку .htaccess в Apache, если сказанное выше произвело на вас впечатление.

Интерпретация базирующаяся на файлах и URI

То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.

Apache

Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки. Первый тип запросов использует конфигурационные блоки или , второй — блоки .

Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.

Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.

Так как Apache может оперировать и c файловой системой, и с webspace, то он в основном опирается на методы работы с файловой системой. Это видно в некоторых решениях в дизайне архитектуры веб-сервера, например, в использовании файлов .htaccess для конфигурирования на уровне директорий. Документация к Apache не рекомендует использовать URI-блоки для ограничения доступа для запросов к файловой системе.

Nginx

Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.

Эта особенность прослеживается в том как для Nginx конструируются и интерпретируются конфигурационные файлы. В Nginx нет способа создать конфигурацию для заданной директории, вместо этого он парсит URI.
Например, основными конфигурационными блоками в Nginx являются и . В блоке определяется хост, который будет обслуживаться, блок отвечает за обработку части URI, которая идет после имени хоста и номера порта. Таким образом, запрос интерпретируется как URI, а не как путь в файловой системе.

В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.

Эти подходы (интерпретация запроса как пути в файловой системе и как URI) могут показаться похожими, но тот факт что Nginx рассматривает запросы как URI, а не как пути в файловой системе позволяет ему легче справляться одновременно и с ролью веб-сервера, и с ролью прокси. Nginx конфигурируется так, чтобы отвечать на различные шаблоны запросов. Nginx не обращается к файловой системе до тех пор пока он не готов обслужить запрос, что объясняет почему он не реализует ничего похожего на файлы .htaccess.

Модули

И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.

Apache

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

Apache использует эту функциональность для решения широкого круга задач. Благодаря зрелости платформы существует огромное множество модулей, которые могут изменять ключевые особенности сервера, например модуль mod_php позволяет включать PHP-интерпретатор в кажого воркера.

Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL'ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.

Nginx

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

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

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

Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL'ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.

Поддержка, совместимость, экосистема и документация

В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.

Apache

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

Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.

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

Nginx

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

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

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

Совместное использование Apache и Nginx

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

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

Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx'у, а тот в свою очередь будет передавать ее пользователю.

Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.

Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.

Введение

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

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

Суть ошибки понятна из её содержимого. Такое бывает из-за того, что терминация TLS-трафика происходит на стороне прокси (Nginx), т.е. запросы пользователей приходят на 443 порт, а backend с сайтом на битрикс работает на http – обычно 80 или иной другой порт, а потому от прокси до бэкенда трафик идёт уже незашифрованный. Сам apache, который является конечной точкой в схеме при проксировании, должен понимать, что сайт работает с использованием протокола https, т.е. при выводе информации в phpinfo значение переменной $_SERVER[‘SERVER_PORT’] должно быть 443, а не 80, и в таком случае никакой некорректной подстановки осуществляться не будет.

  • Самым простым решением является использовать 80 или 443 порт в зависимости от используемого протокола – реализация взята с сайта битрикс и настраивается через конструкцию map. Например, на сервере с битрикс создается файл /etc/nginx/bx/settings/schema.conf со следующим содержимым:
map $http_x_forwarded_proto $balancer_port {
    default 80;
    "https" 443;
}
 map $http_x_forwarded_proto $balancer_https {
     default "NO";
     "https" "YES";
}

Если переменная $http_x_forwarded_proto в Nginx содержит в себе https, то в новые переменные $balancer_port и $balancer_https записывается значение 443 и YES соответственно.

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

proxy_set_header Host $host:80;

На следующую:

proxy_set_header Host $host:$balancer_port; 
proxy_set_header HTTPS $balancer_https;

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

  • В своё время по этой проблеме я также писал в поддержку битрикса и тогда они ещё предложили такое костыльное решение, как мне кажется. Но оно имеет право на жизнь, т.к. работает. В dbconn.php надо добавить:
if (($pos = strpos($_SERVER['HTTP_HOST'], ':')) !== false)
{
$HTTP_HOST = $_SERVER['HTTP_HOST'] = substr($_SERVER['HTTP_HOST'],0,$pos);
}

$_SERVER["HTTPS"] = "On";
$_SERVER['SERVER_PORT'] = 443;

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

  • И есть ещё один из самых правильных вариантов. Также можно внести правки на стороне nginx, который проксирует непосредственно на сам backend к PHP, т.е. в nginx на сервере с bitrix. Например, добавить в nginx.conf в секции HTTP:
http {
...
proxy_redirect    ~^http://([^:]+):443(/.+)$ https://$1$2;
...
}

Директива 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. 

  • в конфигурационном файле httpd по пути /etc/httpd/bx/conf/bx_ext_test.example.org.conf явно указать в директиве ServerName имя домена и схему https. Если используется дефолтный конфиг без отдельных сайтов, то вписать в дефолтный конфиг /etc/httpd/bx/conf/default.conf:
ServerName https://test.example.org

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

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

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

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

location ~* ^/bitrix/subws/ {
     access_log off;
     proxy_pass http://BACKEND;
     proxy_max_temp_file_size 0;
     proxy_read_timeout  43800;
     proxy_http_version 1.1;
     proxy_set_header Upgrade $replace_upgrade;
     proxy_set_header Connection $connection_upgrade;

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

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' 'close';
}

map $http_upgrade  $replace_upgrade {
  default $http_upgrade;
  ''      "websocket";
}

Настройка basic auth

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

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

Но объяснение этого достаточно просто: при использовании модуля ngx_http_auth_basic_module формируется HTTP-заголовок “Authorization”, где зашиваются зашифрованные в base64 логин и пароль, которые пользователь вводит при появлении окна basic auth. А после того, как логин\пароль введён верно, запрос пользователя проксируется на сайт с битрикс, а вместе с ним и заголовок “Authorization”. И тут в игру вступает битрикс и веб-сервер apache – по умолчанию в файле .htaccess сайта, созданного через bitrix-env, есть следующая строка:


        Options +FollowSymLinks
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-l
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
        RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
        RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]

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

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

  1. В .htaccess можно просто закомментировать строку RewriteRule .* – [E=REMOTE_USER:%{HTTP:Authorization}]. Это допустимо при условии, что в дальнейшем не потребуется SSO через Kerberos или NTLM, т.к. как раз на основе переменной REMOTE_USER битрикс и производит сквозную авторизацию.
  2. И самое правильное решение, разумеется, находится на стороне Nginx. Для заголовка HTTP:Authorization просто подставляется пустое значение, а потому битриксу будет неоткуда взять значение для REMOTE_USER, и сайт попросит ввести логин\пароль уже в стандартную форму.
location / {
        proxy_set_header Authorization "";

        ...
        }

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

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

server {
        server_name {DOMAIN};
        listen 80;
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl http2;
        server_name {DOMAIN};
        ssl_certificate "/etc/nginx/ssl/cert.crt";
        ssl_certificate_key "/etc/nginx/ssl/key.key";
        ssl_prefer_server_ciphers on;

        access_log /var/log/nginx/{DOMAIN}.access.log;

        location / {
                proxy_ignore_client_abort on;
                proxy_pass http://{NODE-IP}:80;
                proxy_redirect http://{NODE-IP}:80 /;
                proxy_read_timeout 300;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Port $server_port;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header HTTPS YES;
                proxy_set_header Authorization "";
                
                # for Push&Pull
                location /bitrix/subws {
                proxy_pass http://{NODE-IP}:80;
                proxy_set_header Upgrade $replace_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_redirect http://{NODE-IP}:80 /;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Port $server_port;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header HTTPS YES;
                }
        }

Заключение

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

Что такое X-Frame-Options

Заголовок HTTP ответа от сервера X-Frame-Options служит инструкцией для браузера, он разрешает или запрещает отображение страниц вашего сайта во фрейме. Может иметь три значения:

SAMEORIGIN
Разрешает загрузку страниц сайта во фрейме только если фрейм и страница расположены на одном домене.

DENY
Запрещает загрузку во фрейме.

ALLOW-FROM domain
Разрешает загрузку во фрейме только для указанного домена, не работает для Safari и Firefox.

Защита от фреймов в 1С-Битрикс

В 1С-Битрикс ограничение работы во фрейме включается на странице «Защита от фреймов» (Настройки — Проактивная защита — Защита от фреймов).

Защита от фреймов 1С-Битрикс

На вкладке «Исключения», можно указать страницы сайта, для которых ограничения не будут применяться. Также добавить свою страницу в исключения можно определив константу B_SECURITY_FRAME в значение false, до подключения ядра.

Важно! Чтобы данный функционал 1С-Битрикс корректно работал, заголовок X-Frame-Options на сервере должен быть установлен в значение SAMEORIGIN (как это сделать, читайте далее). Если заголовок отсутствует или установлен в значение отличное от рекомендуемого, «Сканер безопасности» 1С-Битрикс расценит это как потенциальную угрозу сайту и будет показывать соответствующее предупреждение в своём журнале.

Сканер безопасности

Как настроить X-Frame-Options на Nginx

1. Найти секцию server, отвечающую за обработку запросов нужного сайта. Как правило это файлы в /etc/nginx/site-enabled/*.conf

Для версий Bitrix VM ниже 7.0 и чистого nginx скорее всего это будет файл /etc/nginx/nginx.conf или etc/nginx/bx/conf/bitrix.conf

Для Bitrix VM 7.0 и выше заголовок вынесен в отдельный файл /etc/nginx/bx/conf/http-add_header.conf

2. В секцию server нужного сайта добавить или закомментировать строку в зависимости от того хотите вы включить использование заголовка или выключить:

add_header X-Frame-Options SAMEORIGIN;

или

#add_header X-Frame-Options SAMEORIGIN;

3. Перезапустить nginx

systemctl restart nginx.service

или

service nginx restart

Как настроить X-Frame-Options на Apache

1. Найти конфигурационный файл для вашего сайта, зачастую это файлы /etc/apache2/httpd.conf, /etc/apache2/vhost.d/*.conf

2. Добавить или закомментировать строки в зависимости от того хотите вы включить использование заголовка или выключить:


    Header set X-Frame-Options SAMEORIGIN

или


    #Header set X-Frame-Options SAMEORIGIN

3. Перезапустить Apache

Либо внести эти же инструкции в файл .htaccess, при этом перезапуск сервера не требуется.

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

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

Самой известной проблемой является некорректная работа Вебвизора от Яндекс. Данные собираются валидно, но при попытке просмотреть запись посещения возникает ошибка: «Невозможно воспроизвести посещение на данной странице. Возможные причины: Не установлен код счётчика или установлен запрет на отображение страницы во фрейме.»

Варианты добавления в конфиги исключений сводят всю идею X-Frame-Options на ноль, так как могут быть легко подделаны. Поэтому варианты типа приведенного ниже могут использоваться, но не рекомендуются.

location / {
        set $frame_options '';
        if ($http_referer !~ '^https?:\/\/([^\/]+\.)?(yourdomain\.com|webvisor\.com)\/'){
            set $frame_options 'SAMEORIGIN';
        }
        add_header X-Frame-Options $frame_options;
        ...
    }

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

Подключения модуля mod_rewrite

Для включения перенаправления средствами Apache, достаточно чтобы модуль mod_rewrite.so был загружен в Apache.

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

Для того ,чтобы директивы mod_rewrite можно было использовать в .htaccess, надо в конфигурационном файле Apache, в соответствующем разделе "" прописать:

AllowOverride all

После внесения изменений в конфигурационный файл Apache, для вступления в силу этих изменений, нужно перезапустить веб сервер:

apachectl restart

или

apache2ctl restart

В .htaccess для работы перенаправления нужно указать следующую директиву:

RewriteEngine On

Правила Redirect

Эти директивы вы можете прописывать как в конфиге Apache для нужного virtualhost, так в файле .htaccess.

Redirect или RedirectPermanent

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

Если нужно сделать несколько редиректов, то каждый новый редирект нужно написать с новой строки.

Redirect 301 /old-page.html http://new-domain.ru/new-page.html

или

Redirect permanent /old-page.html http://new-domain.ru/new-page.html

Для перенаправления всех запросов на другой сайт вы можете использовать следующую конструкцию:

Redirect 301 / http://new-domain.ru/

или

Redirect permanent / http://new-domain.ru/

RedirectMatch

Этот редирект отличается тем, что в нем можно использовать регулярное выражение. Например, при переносе сайта с Windows на Linux, необходимо сменить все ссылки с *.php на *.aspx:

RedirectMatch /(.*)\.aspx$ /$1.php

RewriteRule

Для работы данного модуля убедитесь в том, что включена опция FollowSymLinks, эту функцию нужно прописать в конфигурационном файле Apache или в файле .htaccess как указано ниже.

Рассмотрим самые распространённые варианты её использования.

Редирект с одного сайта на другой

RewriteEngine On
RewriteCond %{HTTP_HOST} domain1.ua
RewriteRule (.*) http://domain2.ua/$1 [R=301,L]

Редирект с www на без www

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Или более понятный синтаксис

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain\.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

Вы можете использовать любой.

Редирект с без www на www

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.(.*) [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L] 

Альтернатива:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

Перенаправление домена с https на http

Для того, чтобы данное перенаправление работало, должен использоваться только Web-сервер Apache. При использовании связки Nginx+Apache будет возникать ошибка циклической переадресации. Поэтому редирект нужно будет настраивать именно в Nginx

RewriteEngine On
RewriteCond %{SERVER_PORT} ^443$ [OR]
RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

Перенаправление домена с http на https

Для того, чтобы данное перенаправление работало, должен использоваться только Web-сервер Apache. При использовании связки Nginx+Apache будет возникать ошибка циклической переадресации. Поэтому редирект нужно будет настраивать именно в Nginx

RewriteEngine On
RewriteCond %{SERVER_PORT} ^80$ [OR]
RewriteCond %{HTTP} =on
RewriteRule ^(.*)$ https://www.domain.com/$1 [R=301,L]

Модуль ngx_http_rewrite_module, необходимый для настройки перенаправлений, он устанавливается автоматически вместе с Nginx.

Редирект 301 с www.domain.com на domain.com

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена с www, вторая для домена без www:

Секция server для редиректа:

server {
     listen  80;
     server_name  www.domain.com;
     rewrite ^ http://domain.com$request_uri? permanent; 
}

Секция server, где находятся основные настройки домена:

server {
     listen  80;
     server_name domain.com;
.....
}

После внесения изменений в конфигурационный файл Nginx, для вступления в силу этих изменений, нужно перезапустить веб сервер.

service nginx restart

Редирект 301 с domain.com на www.domain.com

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена без www, вторая для домена с www.

Секция server для редиректа:

server {
     listen  80;
     server_name  domain.com;
     rewrite ^ http://www.domain.com$request_uri? permanent; 
}

Секция server, где находятся основные настройки домена.

server {
     listen  80;
     server_name www.domain.com;
.....
}

После внесения изменений в конфигурационный файл Nginx, для вступления в силу этих изменений, нужно перезапустить веб сервер.

service nginx restart

Редирект 301 с https на http

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для https(443 порт), вторая для http(80 порт).

Секция server для открытия по https(443 порт) и настройки редиректа:

server {
   listen  443;
   server_name  www.domain.com;
   rewrite ^ http://www.domain.com$request_uri? permanent; 
}

Секция server, для открытия по http(80 порт), где находятся основные настройки домена.

server {
   listen  80;
   server_name www.domain.com;
.....
}

После внесения изменений в конфигурационный файл Nginx, для вступления в силу этих изменений, нужно перезапустить веб сервер.

service nginx restart

Минимальные требования

  • Возможность установить PHP не ниже 7.2
  • Версия MySql - 5.7 и выше.
  • Возможность выставить директиву php: memory_limit = 512M
  • Возможность выставить директиву php: mbstring.func_overload 2 ( до версии битрикс 18.5)  далее  не требуется.
  • Возможность выставить директиву php: mbstring.internal_encoding UTF-8
  • Возможность включить любой из акселераторов php Zend OPcache или APC
  • "Монитор производительности Битрикс" должен выдавать среднее значение не ниже 30
  • Возможность установить letsencrypt сертификат
  • Свободное пространство на сервере не менее двух кратного размера сайта.
    1. Минимальные системные требования

      1. Процессор не менее 1x2000MHz
      2. Жесткий диск SSD
      3. Оперативная память не менее 1Gb
      4. RAID 1 – использовать 2 диска

     Список официально рекомендованных площадок  Shared хостинг,VPS,VDS.
     Рекомендованный VPS хостинг  (для небольших проектов). 
     Рекомендованный  shared хостинг (для   небольших проектов)  по запросу в сапорт могут разместить сервер в Питере Германии, дать ssh и есть возможность расширить  размер жесткого диска на всех тарифах.

    Минимальные системные требования

    1. Процессор не менее 1x2000MHz
    2. Жесткий диск SSD
    3. Оперативная память не менее 1Gb
    4. RAID 1 – использовать 2 диска

    Рекомендованные требования

    1. Возможность установить PHP не ниже 7.4
    2. Версия MySql - 5.7 и выше.
    3. Возможность выставить директиву php: memory_limit = 4096M
    4. Возможность выставить директиву php: mbstring.func_overload 2  ( до версии битрикс 18.5)  далее  не требуется.
    5. Возможность выставить директиву php: mbstring.internal_encoding UTF-8
    6. Возможность включить акселератор php Zend OPcache
    7. "Монитор производительности Битрикс" должен выдавать среднее значение 90-320
    8. Возможность установить letsencrypt сертификат
    9. Сервер должен проходить официальный тест 1с-Битрикс.
    10. Свободное пространство на сервере не менее трех кратного размера сайта.
    11. Доступ SSH
    12. Рекомендуемая технология Nginx+apache2+PHP-FPM
    13. Самая быстрая Nginx+PHP-FPM
    14. Рекомендуемое окружение + 1C-Битрикс: Виртуальная машина

    Рекомендованные системные требования

    1. Выделенный сервер
    2. Жесткие диски RAID1 2 и более дисков
    3. Оперативная память 16Gb - 64Bg ( все лишнее можно использовать под php mysql sphinx, больше особо смысла нет)
    4. Жесткие диски NVMe SSD
    5. ( в крайнем случае HDD и то рассматривать как хранилище для upload)
    6. Процессор 8-9 ой серии
    7. Приоритет более высокочастотный процессор с меньшим количеством ядер, чем больше количество ядер с меньшей частотой. Поскольку некоторые процессы невозможно распараллелить. Рекомендовано максимально быстрый процессор, 8-9 ой серии
    8. Разница между NVMe SSD и обычным SSD составляет более 30% производительности, в ряде тестов более 700%
    9. Оперативная память не менее 8Gb желательно от 16Gb и выше, при использование VPS,VDS серверов учитывайте что некоторые виды виртуализации сделаны таким образом что выделяя 512 мегабайт, по факту имеют меньший объем поскольку в эту память входит и поддержка самого контейнера, в таком случае рекомендуется брать тариф на 1 выше минимально подходящего.
    10. RAID 1 – использовать 3 диска ( в случае поломки 1 из дисков рейд все еще остается отказоустойчивим) рекомендовано использование SSD с поддержкой NVMe как минимум под базы данных.
    11. Рекомендуется отдельный от RIAD массива бэкап диск, или любое другое облачное хранилище или FTP сервер

    Рекомендуем посмотреть:
    Сервера в Германии и Финляндия Hetzner
    Сервера в России (Питер) Chipcore
    Яндекс облако  От VPS до полного Kubernetas