Redirect all http requests to https with nginx

Solution at a Glance

In Nginx, you can accomplish most redirects with the built-in directive. This directive is available by default on a fresh Nginx installation and can be used to create both temporary and permanent redirects. In its simplest form, it takes at least two arguments: the old URL and the new URL.

You can implement a temporary redirect with the following lines in your server configuration:

Temporary redirect with rewrite

This redirect instructs the browser to direct all requests for to . This solution, however, works only for a single page, not for the entire site. To redirect more than a single page, you can use the directive with regular expressions to specify entire directories instead of just single files.

matches regular expression patterns in parenthesis. It then references the matched text in the redirect destination using expression, where is the first group of matched text. In more complex examples, subsequent matched groups are given numbers sequentially.

For example, if you wanted to temporarily redirect every page within to , you could use the following:

Temporary redirect with rewrite

By default, the directive establishes a temporary redirect. If you would like to create a permanent redirect, you can do so by replacing with at the end of the directive, like this:

Permanent redirects

Let’s move on to some specific examples.

Example 2 — Creating a Persistent Experience Despite Single Page Name Changes

Sometimes, it is necessary to change the names of individual pages that have already been published and received traffic on your site. Changing the name alone would cause a 404 Not Found error for visitors trying to access the original URL, but you can avoid this by using a redirect. This makes sure that people who have bookmarked your old pages, or found them through outdated links on search engines, will still reach the correct page.

Let’s imagine your website had two separate pages for products and services called and respectively. Now, you’ve decided to replace those two pages with a single offer page called instead. We will configure a simple redirect for and to .

We assume you have your website configured as follows:

Assumed original server block configuration

Configuring the redirects is as simple as using two directives.

Redirects added to the original configuration

The directive accepts the original address that has to be redirected as well as the destination address of a new page. Since the change here is not a temporary one, we used in the directive as well. You can use as many redirects like that as you wish to make sure your visitors won’t see unnecessary Not Found errors when moving site contents.

Creating Controller File Using Nginx Rewrite

Using rewrite, you can route many incoming original URL to a master controller template that will serve those request.

The following rewrite example explains this.

rewrite ^/linux/(.*)$ /linux.php?distro=$1 last;

In the above example, when you call thegeekstuff.com/linux/centos URL, it will get rewritten using the above rule and it will serve the page with this rewritten URL: thegeekstuff.com/linux.php?distro=centos

As you see above, any URL that has matches the pattern here (i.e /linux/ in the URL) will be served by linux.php, but the last portion in the original incoming URL will be used as an value for the distro argument in the linux.php controller.

So, the above rewrite rule will transform the incoming URL like this:

• linux/centos becomes linux.php?distro=centos
• linux/debian becomes linux.php?distro=debian
• linux/redhat becomes linux.php?distro=redhat
• etc.

Similar to previous example, we are using $1 in the replacement string to capture anything that is inside the 1st parenthesis ( ) in the reg-ex. In this case, this is the last part of the original incoming URL.

We are also using the last flag here to instruct nginx to stop search for further rewrite directives in the current-block and move-on to the next matching location for further search.

Rewrite Break Flag in Location Context

In this example, we’ve placed the rewrite condition inside location directive.

In this example, the location directive is /data/, which also matches the $1 in the replacement string given below.

location /data/ {
    rewrite ^(/data/.*)/geek/(\w+)\.?.*$ $1/linux/$2.html break;
    return  403;
}

This is what would’ve happened if you used “last” flag above:

• So, if you had “last” as the flag, after the initial rewrite of the URL, Nginx will typically look for the next rewrite directive for the new URL.
• In that case, Nginx will keep redirecting to the same location data and keep processing the same rewrite rule for maximum of 10 times, and finally it will return the 500 error code.

Since, we don’t want the above behavior, we’ve used “break” as the flag here which will just stop processing the rewrite blocks any further.

To use rewrite directive effectively inside location context, you need to understand the details of how location works: 13 Nginx Location Directive Examples including Regular Expression Modifiers

Приемы оптимизации

«Легкий» контент

Виртуальный диск.
Создаем виртуальный диск (tmpfs или ramfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент) переносим туда и в конфиге nginx, отдельно прописываем Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем(при старте системы автоматически будет создаваться диск, размером 1G)
Тут следует обратить внимание на следующее обстоятельство: если статический файл попадает в системный кеш, то скорость его отдачи с системного кеша равняется скорости отдачи с виртуального диска. Другими словами если общее количество всей раздаваемой «легкой» статики небольшое, то надобность в виртуальном диске отпадает (Спасибо maxp за то что побудил меня провести тесты и убедится в этом)

Сжатие контента gzip-ом
Запускаем в нашей виртуальной папке в конфиг nginx добавляем строчку gzip_static on:Также можно включить online упаковку для динамических файлов:

Заголовки для проксирования контента
Указание в заголовках времени жизни статического контента также приведет к уменьшению нагрузки

Для этого будем использовать директиву expires. Если контент не будет меняться, со вренем можно использовать expires max. Даже expires 1d даст хороший результат

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

«Тяжелый» контент

Вначале надо обратить внимание на то, не используется ли swap при отдаче контента, если да то это может быть проблемой, если swap находится на обычном SATA-винчестере. Свопиться любит metod ядра «sendfile», это безусловно прогрессивная технология, но использование swap будет существенно влиять на отдачу и тогда попробуйте sendfile отключить директивой sendfile off и подберите оптимальное заначение для output_buffers, например output_buffers 2 64k;
Пример настройки с выключеным sendfile:Обращаю ваше внимание на то, что многое будет зависеть от ядра, используемого системой, мне это помогло на ядрах >= 2.6.27.
Если позволяет оперативная память, создайте виртуальный диск, на который поместите самые «запрашиваемые» файлы, со временем, скажем, раз в 10 минут вы можете корректировать список этих файлов
Теперь мы можем применить директиву try_files:Если файл не будет найден, на виртуальном диске будет обращение к backend.
Как правило «горячий контент» составляет менее 10% от общего объема.
Если свою программу по формированию кеша писать нет возможности, используйте директиву proxy_storeПри такой конфигурации каждый запрошеный файл помещается в кеш.
Со временем кеш надо как-то чистить, самый простой способ запускать на кроне:(если файл из кеша не запрашимвается более 60 минут, мы его удаляем)
Если storage большой, занимает терабайты — оперативой вопрос не решить. Можно на фронтенд-е собрать RAID. Не советую использовать fake-raid, это головная боль при апгрейде и при пропадании света! Берем побольше винтов SAS, берем полноценный RAID-котроллер (никаких hostraid!). Монтируем туда swap, spool и кеш.Для нечасто меняющегося контента и нечастой перезаписи кеша можно применять SSD-винчестеры. Это работает быстро, у таких винчестеров нет такой характеристики как seek-to-seek, малый расход энергии (например для Intel X25-M 0,15Вт), хорошая скорость отдачи (до 250 MB/s).
Кеширование проксированых запросов.
23 марта 2009 года вышла очередная бета nginx 0.7.44, в которой появилась экспериментальная поддержка кеширования проксированных запросов

Трудно переоценить важность этого события для пользователей nginx. Автор nginx вручает нам мощный инструмент в управлении раздачи большого объема статики.
Почему нужен такой кеш? Ответ на этот вопрос главным образом связан с разной «стоимостью» дисковой операции и сетевой операции

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

Converting Rules that Forward Dynamic Requests to an App Server

Administrators often use Apache rewrite rules like the following to serve static assets directly if they exist and forward dynamic requests to an application server.

Specifically, the blocks of rules perform these functions:

• The directive specifies the local disk directory where content is stored.
• The first block of rules detects whether the file /system/maintenance.html exists – it’s a common practice among website administrators to create this file as a signal that the website is temporarily unavailable due to maintenance. If file exists, it is served no matter what file is requested (effectively, the rule rewrites all requests to maintenance.html). Presumably, the rewrite results in the sending of a maintenance notification to the browser.
• The next three blocks serve these static assets if they exist:
  • The requested file
  • The index.html file in the directory named at the end of the URL
  • Any file with the .html extension
• The final rule comes into play if none of the three types of file exist. It passes the request to a cluster of application servers.

Here’s the conversion for NGINX Plus. The directive corresponds to the Apache directive. The directive replaces the remaining rules, using a named location () as the final rewrite and defining a corresponding block that proxies requests to the application server:

Типы статического контента

Использование вложенных if

Вложенные if в конфигурации nginx запрещены, поскольку это вовсе не языковая конструкция nginx, а обычная директива из модуля rewrite, использование которой в ее же собственном контексте if не предусмотрено. Использование списка условий, разделенных логическими операторами «и» и «или» тоже не предусмотрено. Обычно для эмуляции вложенных условий с использованием директивы if предлагают использовать регулярные выражения. Например, проверить, что имя, указаное в HTTP хедере HOST, соответствует значению localhost, а в URI присутствует аргумент «a» (в этом случае переменная $arg_a будет не пустой), можно так:

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

В данном примере мы соединили через произвольно выбранный нами разделитель :: три переменных $host, $goodhost и $arg_a и присвоили это значение переменной $cond. А регулярное выражение, с которым мы сопоставляем это значение, проверяет, что его первая часть (до разделителя ::) и вторая часть (до второго разделителя ::) равны, а последняя часть (после второго разделителя) не пуста.

В полном виде конструкция проверки примет вид:

Sticky notes

rewrite ^/install/?$ /install.php;
        rewrite ^/doc/(+)/?$ /doc.php?cat=$1;
        rewrite ^/~(+)/doc/(+)/?$ /doc.php?project=$1&cat=$2;
        rewrite ^/~(+)/?$ /index.php?project=$1;
        rewrite ^/~(+)/api/(+)/?$ /index.php?project=$1&mode=$2;
        rewrite ^/all/?$ /list.php;
        rewrite ^/api/(+)/all/?$ /list.php?mode=$1;
        rewrite ^/~(+)/api/(+)/all/?$ /list.php?project=$1&mode=$2;
        rewrite ^/rss/?$ /list.php?rss=1;
        rewrite ^/~(+)/rss/?$ /list.php?project=$1&rss=1;
        rewrite ^/all/(+)/?$ /list.php?page=$1;
        rewrite ^/api/(+)/all/(+)/?$ /list.php?mode=$1&page=$2;
        rewrite ^/~(+)/all/(+)/?$ /list.php?project=$1&page=$2;
        rewrite ^/~(+)/api/(+)/all/(+)/?$ /list.php?project=$1&mode=$2&page=$3;
        rewrite ^/(+)/?$ /show.php?id=$1;
        rewrite ^/~(+)/(+)/?$ /show.php?project=$1&id=$2;
        rewrite ^/(+)/(+)/?$ /show.php?id=$1&mode=$2;
        rewrite ^/~(+)/(+)/(+)/?$ /show.php?project=$1&id=$2&mode=$3;
        rewrite ^/api/(+)/(+)/?$ /show.php?mode=$1&id=$2;
        rewrite ^/~(+)/api/(+)/(+)/?$ /show.php?project=$1&mode=$2&id=$3;
        rewrite ^/(+)/(+)/?$ /show.php?id=$1&hash=$2;
        rewrite ^/~(+)/(+)/(+)/?$ /show.php?project=$1&id=$2&hash=$3;
        rewrite ^/(+)/(+)/(+)/?$ /show.php?id=$1&hash=$2&mode=$3;
        rewrite ^/~(+)/(+)/(+)/(+)/?$ /show.php?project=$1&id=$2&hash=$3&mode=$4;
        rewrite ^/api/(+)/(+)/(+)/?$ /show.php?mode=$1&id=$2&hash=$3;
        rewrite ^/~(+)/api/(+)/(+)/(+)/?$ /show.php?project=$1&mode=$2&id=$3&hash=$4;
        rewrite ^/api/(+)/(+)/(+)/(.*)$ /show.php?mode=$1&id=$2&hash=$3&password=$4;
        rewrite ^/~(+)/api/(+)/(+)/(+)/(.*)$ /show.php?project=$1&mode=$2&id=$3&hash=$4&password=$5;

Redirect All HTTP traffic

Edit or append as follows in your nginx.conf:

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

The return directive stops processing and returns the specified code to a client. The non-standard code 444 closes a connection without sending a response header. In above example, we are returning HTTP code 301: One can use the following code:

• HTTP/301 – The HTTP response status code 301 Moved Permanently is used for permanent URL redirection
• HTTP/302 – The HTTP response status code 302 Found is a common way of performing URL redirection with Moved Temporarily code.

In addition, a URL for temporary redirect with the code 302 can be specified as the sole parameter. Such a parameter should start with the “http://”, “https://”, or “$scheme” string. A URL can contain variables.

Flyspray

location / {
			rewrite ^/.*\?do=admin&area=prefs$ /index.php?do=admin&area=prefs break;
			rewrite ^/(+)$ /index.php?do=details&task_id=$1 break;
		}

		location /task {
			rewrite ^/task/(+)$ /index.php?do=details&task_id=$1 break;
			rewrite ^/task/(+)comment(+)$ /index.php?do=details&task_id=$1comment$2 break;
			rewrite ^/task/(+)/depends$ /index.php?do=depends&task_id=$1 break;
			rewrite ^/task/(+)/depends&prune=(+)$ /index.php?do=depends&task_id=$1&prune=$2 break;
			rewrite ^/task/(+)/edit$ /index.php?do=details&task_id=$1&edit=yep break;
		}

		location = /newtask {
			rewrite ^(.*)$ /index.php?do=newtask break;
			rewrite ^(.*)$ /index.php?do=newtask break;
		}

		location /newtask {
			rewrite ^/newtask/proj(+)$ /index.php?do=newtask&project=$1 break;
		}

		location = /reports {
			rewrite ^(.*)$ /index.php?do=reports break;
		}

		location = /myprofile {
			rewrite ^(.*)$ /index.php?do=myprofile break;
		}

		location /user {
			rewrite ^/user/(+)$ /index.php?do=user&id=$1 break;
		}

		location = /logout {
			rewrite ^(.*)$ /index.php?do=authenticate&logout=1 break;
		}

		location /admin {
			rewrite ^/admin/(+)$ /index.php?do=admin&area=$1 break;
			rewrite ^/admin/editgroup/(+)$ /index.php?do=admin&area=editgroup&id=$1 break;
		}

		location /pm {
			rewrite ^/pm/proj(+)/(+)$ /index.php?do=pm&project=$1&area=$2 break;
			rewrite ^/pm/editgroup/(+)$ /index.php?do=pm&area=editgroup&id=$1 break;
		}

		location /edituser {
			rewrite ^/edituser/(+)$ /index.php?do=admin&area=users&user_id=$1 break;
		}

		location = /register {
			rewrite ^(.*)$ /index.php?do=register break;
		}

		location = /lostpw {
			rewrite ^(.*)$ /index.php?do=lostpw break;
		}

		location = /roadmap {
			rewrite ^(.*)$ /index.php?do=roadmap break;
		}

		location /roadmap {
			rewrite ^/roadmap/proj(+)$ /index.php?do=roadmap&project=$1 break;
		}

		location = /toplevel {
			rewrite ^(.*)$ /index.php?do=toplevel break;
		}

		location /toplevel {
			rewrite ^/toplevel/proj(+)$ /index.php?do=toplevel&project=$1 break;
		}

		location = /index {
			rewrite ^(.*)$ /index.php?do=index break;
		}

		location /index {
			rewrite ^/index/proj(+)$ /index.php?do=index&project=$1 break;
		}

		location /proj {
			rewrite ^/proj(+)$ /index.php?project=$1 break;
		}

Configure DNS Records

In order to set up the desired redirect, to or vice versa, you must have an A record for each name.

Open whatever you use to manage your DNS. For our example, we’ll use the DigitalOcean DNS.

If a domain (also known as a zone) record does not already exist, create one now. The hostname should be your domain, e.g. , and the IP address should be set to the public IP address of your Nginx server. This will automatically create an A record that points your domain to the IP address that you specified. If you are using another system to manage your domain, you may need to add this manually.

Next, add another A record with “www” as the hostname (or “www.example.com” if the partial subdomain doesn’t work), and specify the same IP address.

When you have created both records, it should look something like this:

Note: This will also work with CNAME records, as long as the canonical name’s A record refers to the IP address of your Nginx web server.

Now your server should be accessible via the www and non-www domain, but we still need to set up the redirect. We’ll do that now.

Как конвертировать опции htaccess для серверов Nginx

Существует специальный Nginx converter – это онлайн-сервис, который необходим для перевода синтаксиса файла htaccess в синтаксис конфигурационного документа сервера Nginx. То есть все, что вам понадобится сделать, – это ввести директивы файла htaccess в конвертер, затем скопировать результат, и вставить в конфигурации Nginx

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

Если возникает ошибка 500, значит его нельзя использовать для перевода – в нем содержится ошибка.

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

Если вы захотите добавить в Nginx свои страницы с ошибками, что весьма правильно, то вместо ErrorDocument, вам нужно будет писать, к примеру, вот так: error_page 404 http://domen.ru/error/404.htm. И так вы сможете написать для каждой страницы. Только не забудьте предварительно создать страницы с ошибками. Только потом вы сможете прописать для них путь.

В качестве защиты папок в htaccess часто указывали директиву для запрета листинга каталогов. Для этого писали следующую опцию: Options -Indexes. В Nginx она будет выглядеть совсем по-другому: autoindex off. А для активации листинга укажите вместо off слово on. К сожалению, директиву IndexIgnore через конвертер у вас перевести не получится. Потому вы не сможете при открытом листинге скрывать какие-либо файлы на сервере Nginx. Зато вы сумеете указать свой вариант индексного файла. Для этого нужно прописать вместо DirectoryIndex одно слово: index, и к нему добавить перечень файлов, которые нужно считать индексными.

Некоторые директивы так же легко переводить в Nginx, как и опцию DirectoryIndex. К примеру, директива определения основной кодировки для сайта AddDefaultCharset. Она нужна для того, чтобы все браузеры видели сайт в одной кодировке. Настройка этой опции исключит появление несвязных закорючек на страницах вашего ресурса. Кроме того, вы сможете создать версии портала на другом языке. Чтобы сделать это в Nginx, нужно указать директиву Charset и название кодировки.

Если вы хотите заблокировать доступ к сайту только для некоторых пользователей, то необязательно прописывать сначала Allow from all, а потом указывать исключения. В Nginx достаточно прописать каждый IP-адрес в отдельной строчке после директивы Deny. Например:

А если нужно разрешить доступ только некоторым IP-адресам, то нужно сначала его запретить для всех при помощи директивы Deny all. А потом так же, как и с deny в предыдущем примере: указать в каждой строке по одному IP-адресу, только уже с директивой Allow. Для блокировки какого либо-файла или папки вместо тегов <Files></Files> вам следует писать сначала опцию location, а затем в скобках {} указывать директивы deny и allow. Например, вот как будет выглядеть блокировка файла passwd.html для всех, кроме IP-адреса 81.222.144.12:

А что касается установки пароля на определенные файлы, то в Nginx это делать еще проще, чем если бы прописывали эту опцию в документе htaccess. Вместо того, чтобы указывать четыре директивы, вам необходимо будет указать всего две. В первой строчке необходимо написать опцию auth_basic и в кавычках указать обращение к пользователю, который хочет авторизоваться. А во второй auth_basic_user_file вам следует написать путь к файлу с паролями, которые необходимы для аутентификации.

Единственное, с чем вам придется изрядно помучиться – это перевод директив модуля mod_rewrite в формат настроек Nginx. С этим действительно все сложно, поскольку вам придется изучить синтаксис Nginx, чтобы понять, как активировать на сервере перенаправление URl. В любом случае, вам понадобится директива location, которая нужна для указания адреса переадресации. В скобках вместо директивы RewriteCond, обозначающей условия перенаправления ссылки, нужно писать if. А вместо правила переадресации RewriteRule пишите просто Rewrite.

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