Поиск по сайту OpenCart Club
Показаны результаты для тегов 'nginx'.
Найдено: 2 результата
-
php-fpm Настройка NGINX в режиме PHP-FPM для работы OpenCart
mpn2005 опубликовал запись в блоге в OpenCart DIY - Бери и делай
Веб сервер nginx позволяет работать в разных режимах, как с использованием интерпретатора php, так и без. Для работы OpenCart лучше выбирать оптимальный режим работы php-fpm. Многих данный режим пугает тем, что в данном случае файл htaccess напрочь игнорируется и все необходимые настройки нужно вносить в конфиг nginx. Но в этом нет ничего сверх сложного. Конфигурационный файл - это обычный текстовый файл на сервере, который подчиняется определённым правилам. И по данному поводу можно найти много готовых описаний и инструкций. Данная статья не претендует на уникальность, а просто представляет краткую выжимку по настройкам, учитывая особенности работы с движком OpenCart и сборками на его основе. Для удобства будут приводится примеры настройки с использованием панели ISPmanager. Основные настройки будут касаться секции location, и зависимость описания от используемой панели будет минимальной. Для начала переведём nginx в режим работы php-fpm. Для этого в панели сделаем следующие настройки разделе WWW-домены для нужного сайта: 1. Выбираем в списке нужный сайт, если их несколько, и жмём кнопку "Изменить". 2. Находим настройки PHP и настраиваем следующим образом: Обратите внимание, что версия php у вас может отличаться. При необходимости, можно эту версию изменить на нужную, но этот вопрос выходит за рамки данной статьи. После сохранения настроек будет работать почти всё, что и раньше. Если в настройках OpenCart отключены ЧПУ ссылки, то всё будет работать, как и работало до переключения режима работы. Теперь можно приступать к непосредственной настройке самого конфигурационного файла nginx для текущего сайта. Для этого в списке www доменов находим нужный нам и нажимаем справа на иконку с тремя точками. В выпадающем меню выбираем пункт "Конфиг": Вот примерный конфигурационный файл, который будет создан у вас по умолчанию: В конфигурации у вас будет две секции server, если у вас включено защищённое соединение SSL (и оно должно быть обязательно включено). Если у вас включен принудительный редирект с http на https, то можно редактировать только секцию server для https. Определить её легко: в самом начале есть параметр с указанием сертификата ssl_certificate. Также в этой секции указан параметр listen с указанием порта 443: listen 8.8.8.8:443 ssl Но лучше делать настройки сразу в двух секциях server, чтобы не допустить механической ошибки. На данный момент нас интересует вот эта часть конфигурационного файла: location / { location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @php; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 365d; } } Все дальнейшие изменения мы будем вносить внутри этой секции "location /". В первую очередь нам не хватает вот такой директивы: if (!-e $request_filename){ rewrite ^/(.+)$ /index.php?_route_=$1 last; } Данное условие очень простое: если сервер не может найти файл по указанному в запросе пути, то запрос будет переписан на вызов index.php, а в параметр _route_ будет передан запрашиваемый путь. Именно это и позволит корректно отрабатывать всем ЧПУ ссылкам движка. Это правило является аналогом записи в файле htaccess: RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] На этом можно было бы и закончить, но стоит внести ещё некоторые изменения для улучшения безопасности. Рассмотрим более внимательно вот эту секцию: location ~ [^/]\.ph(p\d*|tml)$ { Тут отбираются все все подходящие динамические файлы с типами .php (в том числе с числами в окончании) и .phtml Но у движка OpenCart в штатном режиме есть всего две точки входа для вызова php файлов через web окружение - это index.php и admin/index.php Есть ещё install/index.php, но она используется только при установке движка. Учитывая данные обстоятельства, логично запретить прямое выполнение всех остальных php скриптов через web окружение, кроме указанных администратором. Сделать это можно следующим образом: location ~ ^/(index|admin/index|install/index)\.php { try_files /does_not_exists @php; } В скобках через разделитель "|" указываем все php скрипты, которые можно выполнять. После завершения установки можно будет сократить это список до такого: (index|admin/index) ВНИМАНИЕ!!! Очень важный момент! После того, как убрали вызов интерпретатора php для всех файлов, кроме указанных, при попытке запроса любого другого php файла он будет отдан как обычный текстовый файл. И при запросе https://test.ru/config.php любой желающий сможет получить содержимое вашего конфигурационного файла, где содержится доступ к БД. Поэтому нам обязательно нужно запретить доступ для всех остальных файлов с расширением php. Ну и заодно к другим типам файлов, которые не стоит отдавать по запросу извне. Сделать это можно простым правилом: location ~* \.(php|log|tpl|txt|twig|xml|ini)$ { deny all; } В скобках через разделитель "|" указываем все расширения файлов, которые мы хотим запретить. Но у нас есть несколько важных файлов, которые пока попали под запрет, например: robots.txt и sitemap.xml. Этот вопрос мы решим чуть позже. А сейчас ещё немного запретов. Запретим открывать файлы, которые начинаются с точки, а также все файлы в папке system: location ~ /\. { deny all; } location ~ ^/system/ { deny all; } Этих запретов вполне достаточно, чтобы сделать невозможным выполнение каких-либо несанкционированных скриптов. А также просмотр логов, текстовых и xml файлов. Теперь нам необходимо открыть доступ к файлу robots.txt, для этого нам нужно такое правило: location = /robots.txt { allow all; } Также пропишем разрешение на открытие sitemap.xml и rewrite правило: location = /sitemap.xml { allow all; rewrite ^/(.*)$ /index.php?route=extension/feed/google_sitemap last; } Если вы используете сторонний модуль сайтмапа, то нужно указать соответствующий route для данного модуля. Если у вас несколько файлов sitemap или вы используете фиды для выгрузки данных, то просто пропишите для них права по аналогии. В итоге мы должны получить вот такую секцию location: Этих настроек достаточно для корректной работы движка OpenCart. И при этом данная конфигурация является безопасной с точки зрения выполнения несанкционированных скриптов php через web окружение. После всех настроек обязательно проверьте правильность работы, сделав запросы по указанному чек-листу (test.ru замените на адрес вашего сайта): https://test.ru/config.php https://test.ru/admin/config.php https://test.ru/admin/1.php https://test.ru/admin/1.txt https://test.ru/admin/1.log https://test.ru/admin/1.xml https://test.ru/system/modification.xml Для всех этих ссылок вы должны получить ошибку "403 Forbidden", вне зависимости от того, есть файл по указанному пути на сервере, или нет. Также проверяем белый список: https://test.ru/robots.txt https://test.ru/sitemap.xml Эти файлы не должны вызывать ошибок и вы должны корректно получать их содержимое. Дополнительно стоит проверить все ваши дополнительные сайтмапы или фиды, если вы их добавляли. Ещё раз повторюсь, что данная настройка является базовой, с небольшими правилами для улучшения безопасности. Но даже уже при такой настройке вы в среднем получите выигрыш 100-200ms для параметра TTFB, по сравнению с остальными режимами работы. -
Nginx, 301 редиректы с http на https протоколы и наоборот Nginx, 301 редирект с http на https протокол Если у вас на сайте есть SSL сертификат для домена, то вы можете настроить https протокол. После чего для 301-го редиректа вам необходимо добавить следующий код в файл конфигурации nginx для домена: server { #... if ($scheme = http) { return 301 https://$server_name$request_uri; } } или server { #... listen server_ip:80; server_name www.site.com; rewrite ^ https://www.site.com$request_uri? permanent; } Nginx, 301 редирект с https на http протокол Обратный пример конфигурации для редиректа с http на https: server { listen 443; server_name www.site.com; rewrite ^ http://www.site.com$request_uri? permanent; } server { listen 80; server_name www.site.com; #... } Nginx, 301 редирект с www на без www Пример 301-го редиректа на основное зеркало без www: server { #... if ($host ~* www\.(.*)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; } } или server { #... server_name www.site.com; rewrite ^/(.*)$ http://site.com/$1 permanent; } Nginx, 301 редирект с без www на с www Обратный пример 301-го редиректа на основное зеркало сайта с www: server { #... server_name site.com; rewrite ^/(.*)$ http://www.site.com/$1 permanent; } server { listen 80; server_name www.site.com; #... } Nginx, 301 редирект для одной страницы Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL: server { #... if ( $request_filename ~ oldpage/ ) { rewrite ^ http://www.site.com/newpage/? permanent; } #... } Nginx, 301 редирект для папки Аналогичный пример 301-го редиректа для папки: server { #... if ( $request_filename ~ oldfolder/.+ ) { rewrite ^(.*) http://www.site.com/newfolder/$1 permanent; } #... } Nginx, 301 редирект с одного домена на другой Если вы сменили домен сайт и хотите перенести вес старого домена на новый, то можно сделать 301-й редирект со старого домена на новый: server { server_name domain.com www.site.com; rewrite ^ $scheme://www.new-site.com; } Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена Если вы планируете изменить свой домен или изменить название предприятия, то пере направление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен: server { server_name site.com www.site.com; rewrite ^ $scheme://www.new-site.com$request_uri permanent; } Nginx, 301 редирект со страниц со слешем "/" на страницы без слеша в конце URL Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него: server { #... rewrite ^/(.*)/$ /$1 permanent; #... } Nginx, 301 редирект со страниц без слеша на страницы со слешем в конце URL Причина делать такой редирект та же, что и в ситуации описанным выше, за исключением того, что редирект необходимо делать со страницы без слеша в конце URL на страницу со слешем в конце URL: server { #... rewrite ^(.*[^/])$ $1/ permanent; #... } Дополнительно Не забудьте перед использованием примеров сменить site.com на свой домен. После внесения изменений в файл конфигурации nginx для домена необходимо перезапустить nginx: service nginx reload или service nginx restart или перезапустить с панели Для редиректа с site.ru/brand/product на site.ru/product при переездах и т.д. добавлять в блок server : if (!-d $request_filename){ set $r 1; } if (!-f $request_filename){ set $r 2$r; } if ($r = 21){ rewrite ^/(.*)/(.*)$ $scheme://$host/$2 permanent; }
