Nginx route all to index php

Как перенаправить все запросы на index.php NGINX?

Доброго времени суток!
Не работает перенаправление на индексный файл в NGINX. Возможно я делаю что то не так.

Клиентская часть работает нормально, то есть переходы по ссылкам типа site/news/1 site/plugins/plugin проходят нормально. Но если пытаться делать это в админке то выкидывается 404

ссылки типа site/adm/plugins/plugin дают 404

На сколько я знаю htaccess не работает в NGINX и настраивать надо конфиг мой конфиг ниже, помогите поправить

server < listen 80; server_name internal.onclinic.local; root /web/sites/internal.onclinic.local/www/; index index.php index.html index.htm; access_log /web/sites/internal.onclinic.local/log/access.log main; error_log /web/sites/internal.onclinic.local/log/error.log; location / < try_files $uri $uri/ /index.php?$args; >location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ < access_log off; expires max; >location ~ \.php$ < try_files $uri =404; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/internal.onclinic.local/www/; fastcgi_param SCRIPT_FILENAME /web/sites/internal.onclinic.local/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /web/sites/internal.onclinic.local/www$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param HTTPS on; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; >location = /favicon.ico < log_not_found off; access_log off; >location = /robots.txt < allow all; log_not_found off; access_log off; >location ~ /\.ht < deny all; >> server

Средний 2 комментария

Источник

Примеры настройки перенаправлений на NGINX

Если в случае с серверами Apache2 для переадресации следует отредактировать файл .htaccess, в Nginx таковой отсутствует. Тем не менее, редирект можно настроить, отредактировав файлы конфигурации виртуальных доменов.

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

• в дистрибутивах, основанных на RPM (CentOS, Red Hat) — /etc/nginx/conf.d/.
• в дистрибутивах, основанных на Debian (Ubuntu, Debian) — /etc/nginx/sites-enabled/.

Как применить настройки редиректа

Чтобы применить редиректы на веб-сервере Nginx, необходимо выполнить последовательно два действия:

1. Добавить соответствующую команду в виртуальный хост выбранного домена.
2. Перезагрузить сервер.

Настройка редиректа

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

Способ №1

Первый представляет собой строку:

rewrite ^ https://$host$request_uri?

Здесь переменная $host является хостом из запросов. Если он отсутствует, следует воспользоваться именем заголовка в поле «Host», если и его нет — подойдет имя сервера.

Переменная $request_uri — это первоначальный запрос с аргументами.

При настройке можно выбрать следующие флаги ():

• permanent — 301 редирект (или постоянный редирект) на страницу с кодом ответа сервера 301.
• redirect — 302 редирект (или временный редирект) на страницу с кодом 302.
• last — завершение обработки и последующий переходом в новый location.
• break — завершение обработки и работа в текущем location.

Способ №2

return https://$host$request_uri;

Здесь можно использовать любой код редиректа, однако самые распространенные случаи — 301 , 302 , 404 .

По завершении редактирования файлов остается проверить, правильны ли они:

Чтобы их применить, необходима перезагрузка Nginx:

Первая команда используется в новых версиях Linux. Вторая — для устаревших версий и FreeBSD.

Практическое использование редиректов

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

Это наиболее распространенное перенаправление, которое позволяет направить весь трафик непосредственно на домен, минуя поддомены. Код редиректа:

Если необходимо получить противоположный эффект (перенаправление на «www» c «без www»):

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

Чтобы организовать перенаправление на другой сайт — например, после изменения адреса сайта — можно воспользоваться командой:

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

Установить перенаправление с http на https (защищенный протокол SSL ) можно следующим образом:

Здесь при всех обращениях domain.ru по протоколу http сработает перенаправление на 443-порт с использованием 301 редиректа для склейки доменов.

Чтобы установить редирект на http с https , достаточно изменить код ответа сервера:

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

При необходимости использовать перенаправление на другой сервер всех запросов:

Здесь за прием запросов браузера и ответ на них отвечает веб-сервер Nginx. Их обработка выполняется сервером с IP-адресом 192.168.0.12 (порт 8080 ). Таким же образом осуществляется и перенаправление на другой Nginx.

Редирект с IP адреса на домен

Перенаправление домена без www на домен с www

В противном случае (редирект с www на без www) нужно использовать такое сочитание:

Перенаправление одного URL

Перенаправление на index.php

Сделать так, чтобы запросы из браузера обрабатывались через index.php можно таким образом:

Если же файл расположен в корневом каталоге, перенаправление на index.php указывается командой:

Перенаправление «после слэша» (/)

Следующий блок позволяет установить перенаправление «после слэша» для домена:

Это приведет к тому, что после ввода адреса http://domain.com/mail пользователь будет перенаправлен на https://mail-server.com/mail-panel.

Стоит добавить в приведенный пример знак « = », чтобы перенаправление относилось только к этому элементу (почта), а не ко всему, что начинается с «mail»:

Перенаправление с изменением типа файла

Еще один вариант будет полезным, когда ссылку на файл HTML нужно автоматически заменить ссылкой на файл PHP:

Несколько доменов, один каталог и один основной домен

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

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

Не стоит забывать об исключении ошибки 404 («страница не найдена»), которая может возникнуть, если кто-то воспользуется ссылкой на товар/страницу с одного из альтернативных доменов. Решить эту задачу можно следующим способом:

Таким образом, все альтернативные адреса, отличные от «.ru», будут направлены на «new-address.ru», который является основным адресом.

Техническое обслуживание сайта

Следующий сценарий подойдет для сайта, который находится на техническом обслуживании. То есть в случае необходимости внесения изменений на сайте. При этом перенаправление будет работать в случае обращения к определенному IP-адресу.

Задача заключается в перенаправлении оставшихся посетителей на страницу, которая будет содержать информацию, подобную «На сайте ведутся технические работы…». Это можно осуществить следующим способом:

location / < if (-f $document_root/technical-break.html) < return 503; >[Standart Code/Parameters] > error_page 503 @maintenance; location @maintenance < if ($remote_addr !~ "^123.123.123.123")< rewrite ^(.*)$ /technical-brea.html break; >>

Вместо подстановочных значений «123.123.123.123» в примере следует вписать IP-адрес своего сервера.

Дополнительные настройки

Свой IP-адрес нужно исключить с редиректа, чтобы сохранить полный доступ к сайту:

if ($remote_addr !~ "^123.123.123.123")

Вместо 123.123.123.123 следует указать IP адрес своего сервера.

Благодаря примеру ниже можно обнаружить, существует ли такой файл (technical-break.html) на сервере:

if (-f $document_root/technical-break.html)

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

Работа над новой версией сайта с перенаправлением на старую

• Задача: начать работу над модернизацией действующего веб-сайта, оставить при этом посетителям доступ к его старой версии.
• Решение: старую версию сайта можно поместить в каталог «old», а в главной директории работать над созданием новой версии.

Перенаправить пользователей на старую версию:

location / < if ($remote_addr !~ "^123.123.123.123")< rewrite ^(.*)$ /old$1 redirect; >[Standart code: try_files $uri $uri/ /old/index.php?$args; ] >

Вместо «123.123.123.123» необходимо подставить IP адрес своего сервера (или адреса).

В случае, если возникает циклическое перенаправление на странице, следует добавить:

Перенаправление в зависимости от IP-адреса посетителя

Приведённый ниже способ предпочтителен с точки зрения SEO-оптимизации, так как при выполнении сценария в ссылках ничего не меняется:

set $WWWDIR "old-version"; if ($remote_addr ~ MY_IP) < set $WWWDIR "new-version"; >root /var/www/[domain]/$WWWDIR/;

При посещении сайта, сервер предоставляет владельца или администратору ресурса ( MY_IP ) файлы из каталога new-version («новая-версия»). Когда страница посещается «сторонним лицом», сервер открывает старую версию сайта.

Перенаправление в зависимости от IP-адреса посетителя и браузера

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

К сожалению, Nginx не поддерживает правила объединения, поэтому здесь следует применить небольшой трюк:

set $WWWDIR "old-version"; if ($remote_addr ~ MY_IP) < set $test okA; >if ($http_user_agent ~ Firefox) < set $test "$okB"; > if ($test = okAokB) < set $WWWDIR "public_html"; >root /var/www/[domain]/$WWWDIR/;

Здесь используется дополнительная переменная $TEST . С первым условием (действительным IP-адресом) она получает значение « okA », а со вторым (браузер Firefox) — дополнительное значение « okB ».

В результате, значением должно быть « okAokB ». И только когда оба условия выполняются одновременно ( $ TEST соответствует « okAokB »), открывается доступ в соответствующий (рабочий) каталог (public_html).

Редирект в зависимости от файлов cookie

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

Хотя в таких ситуациях может помочь подключение через VPN, это не всегда возможно. Здесь применяется еще одно условие — проверка cookie:

server < [. ] set $WWWDIR "old-version"; if ($cookie_name-site = "test") < set $WWWDIR "public_html"; >root /var/www/[domain]/$WWWDIR/; [. ] >

Если в браузере будет сохранен cookie с контентом «text», то файлы нового сайта будут открываться без редиректа.

Очевидно, понадобится механизм для сохранения соответствующего куки в браузере. Здесь достаточно применить директиву PHP:

Она сохраняется на сервере (например, в файле cookie.php). Он добавляется в каталог со старой (для создания cookie) и новой страницей (обновления cookie до его истечения). Данный код выполняет следующую инструкцию:

1. Осуществляется переход по адресу [domain] /cookie.php.
2. Выполняется стандартный переход на сайт.
3. Вместо старого сайта открывается новый.

В приведенном выше примере cookie действителен в течение 5 минут (300 секунд), после чего — если он не будет создан снова — вместо новой страницы снова будет отображаться старая страница. Когда новая страница готова, достаточно удалить эти несколько строк.

Nginx и CloudFlare

В случае использования CloudFlare существует высокая вероятность того, что редирект не будет работать правильно для выбранного IP-адреса, то есть сервис не будет его распознавать.

В этом случае в файле конфигурации виртуального хоста следует добавить:

# CloudFlare IP set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/12; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; real_ip_header CF-Connecting-IP; real_ip_recursive on; # /CloudFlare IP

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

Надежный хостинг для сайта. 14 дней — бесплатно!

Источник

Редирект запросов на index.php в nginx

По всем запросам открывает главную. В $_SERVER[‘REDIRECT_URL’] ничего не попадает.

index.php организован примерно так.

В гугле нашел в нескольких комментах, что $_SERVER[‘REDIRECT_URL’] поддерживается только апачем. Это так? Пока заменил его на REQUEST_URI.

э… $_SERVER — грубо говоря, параметры, которые передаёт сервер вместе с запросами. Что туда засунешь (fastcgi_param), то туда и уйдёт.

# server <> на каждый сайт свой server < listen 192.168.3.9:80; # чтобы без всяких if отправлять куда надо server_name www.site.ru; return 301 $scheme://site.ru$request_uri; # так он сливает запросы с www. и без в один, чтобы в том же аналитиксе всё норм было >server < server_name site.ru 192.168.3.9; listen 192.168.3.9:80; # для ip6 нужны [] access_log /var/log/nginx/site.ru-access.log main buffer=16k; error_log /var/log/nginx/site.ru-error.log; # 404 не будет работать, когда в try_files указан наличествующий /index.php. вместо него в конце надо писать =404 error_page 404 500 502 503 504 /index.php; # root должен писаться 1 раз внутри server<>, ДО location<>, но если ОЧЕНЬ надо, чтобы кидало в определённую диру, можно и для каждой location свой root root /usr/local/web/data/cs2ms.ru; location / < # limit_req zone=one burst=20; try_files $uri $uri/ /index.php; >location /cab/ < # limit_req zone=one burst=2; # тут можно писать /index.php, а не /cab/index.php try_files $uri $uri/ /cab/index.php; >location ~* \.php$ < # limit_req zone=one burst=20; try_files $uri /index.php; fastcgi_index index.php; fastcgi_pass unix:/var/run/php5-fpm.sock; # ибо по умолчанию только GET HEAD fastcgi_cache_methods GET HEAD POST; # Игнорируем заголовки, относящиеся к кешированию, полученные от FastCGI-сервера. игнорирует указанное время экспирации, будет всегда отдавать из кэша, вплоть до inactive=1d fastcgi_ignore_headers Cache-Control Expires Set-Cookie; # Необходимо для передачи cookie в соответствующие переменные, например cookie с именем phpsessid будет находится в переменной $cookie_phpsessid # Если с последними версиями nginx возникли проблемы с передачей cookies или авторизацией — решение: fastcgi_pass_header «Set-Cookie»; fastcgi_pass_header Cookie; # Формируем уникальный ключ; в данном случае различаем пользователей с помощью $cookie_phpsessid fastcgi_cache_key "$server_addr:$server_port$request_uri|$cookie_phpsessid"; # Говорим о том, что использовать надо вышеобъявленную кеш-зону fastcgi_cache fastcgi_cache fastcgi_cache; # Указываем папку для хранения временных файлов fastcgi_temp_path /tmp/nginx/temp 1 2; # Используем вариант из кеша (даже если он устарел) в случае ошибки fastcgi_cache_use_stale updating error timeout invalid_header http_500; # Время жизни кеша для ответов 200, 301 & 302 fastcgi_cache_valid 0s; >> 

php-fpm поставить не забудь, чтобы .php обрабатывать

Источник