Заголовки для кеширования
Когда веб-сервер отдаёт какой-нибудь файл: картинку, css, js или контент страницы, то он должен сказать сколько можно хранить эти данные в кеше.
Картинки можно хранить там вечно, они никогда не изменяются. Многие любят выдавать запрет на кеширование в виде заголовков:
Cache-Control: no-cache,no-store,max-age=0,must-revalidate Expires: -1 Expires: Thu, 19 Nov 1981 08:52:00 GMT Pragma: no-cache
На самом деле, смысла в этом никакого нет для большинства данных, только нагрузка на сервер. И не надо бояться сказать, что файл или страницу сайта можно закешировать.
Во-первых, потому что браузер при следующем обращении к этому контенту при условии, что время хранения кеша просрочено спросит: «а не изменился ли ресурс с момента последнего моего запроса».
И если не изменился, то веб-сервер должен вернуть заголовок 304 Not Modified и не отправлять запрашиваемый файл.
Во-вторых, пользователь всегда может нажать обновить страницу и принудительно послать запрос к серверу не уточняя изменился ресурс или нет.
Важно только правильно определить время хранения кеша. В решение этого вопроса можно исходить из того как часто обновляются данные и насколько это важные данные.
Что случится, если посетитель увидит обновление с опозданием
Какое это разумное опоздание? Подавляющее большинство страниц в интернете чаще умирает, чем обновляется.
Обновляются ленты новостей, а страница с конкретной новостью живёт вечно. Поэтому для подобных страниц можно смело выставить время жизни веша сутки или неделю, т.е. то
разумное время в которое посетитель может вернуться на эту страницу или ваш сайт.
Итак, давайте рассмотрим как браузер спросит не изменился ли запрашиваемый ресурс. Для этого есть два варианта.
Первый — отправить в запросе If-Modified-Since с датой предыдущего запроса.
Второй — отправить в запросе If-None-Match с меткой ETag, которую он получил при предыдущем обращении.
При ответе веб-серве посылает следующие заголовки:
ETag: "1722-59d1cd83fc41f" Cache-Control: max-age=31536000, public
ETag — является уникальной меткой, а Cache-Control сообщает можно ли хранить кеш на промежуточных прокси-сервера и сколько его можно хранить.
В .htaccess укажите:
Header set Cache-Control "max-age=31536000, public"
В заголовой php-скрипта добавьте следующий код если он не обращается к базе и не зависит от других сервисов.
Устранение проблемы прокси-сервера Nginx
На предыдущем скриншоте см. эту информацию:
Первая и вторая строки указывают на возможность разрешения локальных проблем и подключения в розетке. Поэтому nginx должен быть запущен. Чтобы убедиться в этом, можно выполнить команду.
Третья строка указывает источник проблемы. Вы получаете сообщение об ошибке http 502 Bad Gateway. Плохой шлюз HTTP 502 связан с прокси-сайтами. Это означает, что обратный прокси не может подключиться к заднему приложению. В этом случае это ваше ASP.NET Core приложение, которое должно запускаться и прослушиваться в порте 5000 для запросов. Необходимо проверить, запущено ли также веб-приложение.
Чтобы начать устранение неполадок, запустите ту же команду, что и раньше. На этот раз используйте grep для фильтрации порта приложения 5000. Затем запустите .
Этот пример показывает, что в порту 5000 ничего не прослушивается. Таким образом, это является причиной ответа HTTP 502, который приходит из Nginx, так как он может найти процесс, который прослушивается в порту 5000.
Решение заключается в запуске ASP.NET Core приложения. Однако, прежде чем ходить дальше, вы можете просмотреть другой подход для устранения этой проблемы. Не каждая проблема так же проста в исправлении, как простое просмотр нескольких строк контента журнала и поиск первопричины. Иногда необходимо глубоко погрузиться в другие журналы систем и приложений.
Поскольку вы тесно работаете с Nginx при ASP.NET Core приложений в Linux, мы предлагаем узнать, какие журналы Nginx и операционная система обеспечивают устранение неполадок.
Основные ошибки nginx и их устранение
502 Bad Gateway
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в прописаны правильные права
listen = /tmp/php5-fpm.sock listen.group = www-data listen.owner = www-data
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:
server {
...
send_timeout 800;
proxy_send_timeout 800;
proxy_connect_timeout 800;
proxy_read_timeout 800;
...
}
Тут мы выставили ожидание таймаута в 800 секунд.
Upstream timed out (110: Connection timed out) while reading response header from upstream
Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
location ~ \.php$ {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/php5-fpm.sock;
fastcgi_read_timeout 800;
}
800 секунд на ожидание ответа от бекенда.
Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
client_max_body_size 1m;
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до
client_max_body_size 100m;
Также, можно отключить проверку размера тела ответа полностью значением ноль:
client_max_body_size 0;
Следует помнить, зачем ввели это ограничение: если любой пользователь может загружать файлы на неподготовленный сайт, можно сравнительно легко провести DDOS-атаку на него, перегружая входной поток большими файлами.
После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx
304 Not Modified не устанавливается
Если возникает проблема с правильным отображением ответного заголовка сервера , то проблема, скорее всего, в пунктах:
- В секции конкретного сайта включен (Подробнее в документации). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
- if_modified_since установить в , то есть на уровне или конкретного прописать:
Правильность ответа можно проверить с помощью:
- Консоли разработчика браузера (F12) в разделе (не забываем перезагружать страницу);
- Или сторонних сервисов, например last-modified.com.
Пример двойного редиректа
Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен и добавление к урлу в конце слеш. То есть вы хотите такое преобразование:
http://site.ru/catalog -> https://site.ru/catalog
Допустим, у вас сначала был настроен редирект на https подобным образом:
server {
listen 80;
root /var/www/site.ru/public;
location / {
return 301 https://site.ru$request_uri;
}
}
А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.
server {
listen 443 http2;
...................
location / {
rewrite ^(*)$ $1/ permanent;
...................
}
# curl -I -L http://site.ru/catalog HTTP/1.1 301 Moved Permanently Server: nginx Content-Type: text/html Content-Length: 162 Connection: keep-alive Location: https://site.ru/catalog HTTP/2 301 server: nginx content-type: text/html content-length: 162 location: https://site.ru/catalog/ HTTP/2 200 server: nginx content-type: text/html; charset=utf-8 vary: Accept-Encoding
На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:
server {
listen 80;
server_name site.ru www.site.ru;
root /var/www/site.ru/public;
location / {
return 301 https://site.ru$request_uri/;
}
}
Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.
server {
listen 80;
server_name site.ru www.site.ru;
location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
return 301 https://site.ru$request_uri;
}
location / {
return 301 https://site.ru$request_uri/;
}
}
Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.
Использование Web интерфейса для настройки
Если лезть и разбираться в конфигах и командах не очень хочется то можно поставить «Nginx Proxy Manager» https://github.com/jc21/nginx-proxy-manager.
Особенности
- Красивый и безопасный интерфейс администратора на основе Tabler
- Легко создавать домены пересылки, перенаправления, потоки и 404 хосты, ничего не зная о Nginx
- Бесплатный SSL с использованием Let’s Encrypt или используя ваши собственные пользовательские SSL-сертификаты
- Списки доступа и базовая HTTP-аутентификация для ваших хостов
- Расширенная конфигурация Nginx, доступная для суперпользователей
- Управление пользователями, разрешения и журнал аудита
Запускается как докер контейнер
В базе на сколько понимаю работает в SQLite, можно подключить к Mysql.
После установки доступен по http://127.0.0.1:81.
Благодарю Алексея Лустина за информацию.
Пример с nginx rewrite
Теперь другая проблема. Возьмем такой url — http://site.ru/catalog/. В текущем конфиге он превращается в https://site.ru/catalog//. Исправляем это:
server {
listen 80;
server_name site.ru www.site.ru;
location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff)$ {
return 301 https://site.ru$request_uri;
}
location / {
rewrite ^/(.*)/$ /$1;
return 301 https://site.ru$uri/;
}
}
Обращаю внимание на то, что сделано. Я использую без какого-либо флага на конце, чтобы не прекращать обработку директив
В данном случае просто меняется uri и передается дальше. Если запрос приходит со слешом на конце, мы его обрезаем и отправляем в правило редиректа на https. Если слеша нет, то он сразу на редирект уходит. Теперь все в порядке.
Серверные блоки
Независимо от источника установки файлы конфигурации будут содержать серверный блок (или блоки) для веб-сайта, обозначенный словом server. Например:
server {
listen 80 default_server;
listen :80 default_server;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html;
try_files $uri /index.html;
}
Директива server_name позволяет размещать несколько доменов на одном IP-адресе (виртуальные хосты). Выбор домена осуществляется на основании информации в заголовке полученного запроса.
Директива listen задает Nginx имя или IP-адрес узла и TCP-порт, который он должен прослушивать для HTTP-соединений. Аргумент default_server означает, что этот виртуальный хост будет отвечать на все запросы на порт 80, в которых в явном виде не будет указан другой виртуальный хост. Вторая такая директива устанавливает аналогичное поведение для IPv6-соединений.
Обычно для каждого домена или сайта на сервере требуется создать свой файл. Вот некоторые примеры:
1.Обработка запросов к example.com и www.example.com:
server_name example.com www.example.com;
2.В директиве server_name можно использовать маски. Например, *.example.com и .example.com указывают серверу обрабатывать запросы на все поддомены example.com:
server_name *.example.com; server_name .example.com;
3.Обработка запросов ко всем доменным именам, начинающимся с example.:
server_name example.*;
Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.
Это полезно, если ваш сервер работает в локальной сети или вы точно знаете все клиенты, которые будут осуществлять запросы, например, front-end прокси-серверы, у которых записи в настроены на IP-адрес Nginx.
Архитектура и конфигурация Nginx
Установка на Linux возможна двумя способами — из предварительно собранного бинарного файла (пакета) или с помощью исходного кода.
Первый способ самый простой, но второй позволяет подключить различные дополнительные модули, расширяющие возможности сервера. Установка с помощью исходного кода применяется сравнительно редко, поэтому ее особенности рассматривать здесь не будем.
Установка Nginx на Windows возможна с помощью интерфейса Win32 API. Однако, такой вариант будет гораздо менее эффективен, даже в серверных версиях и не может быть рекомендован для широкого применения.
Описание проблемы
Для каждого из видов подключения нужна своя аутентификация и отдельный набор ролей доступа. При одной публикации доступ пересекается, стандартные «грабли»: при подключении телефонии тонкий клиент на автомате подключается под сервисным пользователем телефонии.
Разнесение на отдельные публикации
Решает проблему пересечения, но не решает вопрос контроля доступа. При публикации HTTP сервисов расширений публикуются все, потенциально под одним пользователем могут подключится к другому сервису.
Так же остается проблема если нужна Basic аутентификация на уровне кода сервиса.
Что такое Nginx
Nginx (NGINX, Engine-X, «Энжин-кс») — это бесплатный веб- и почтовый прокси-сервер с непоточной (асинхронной) архитектурой и открытым кодом.
Разработку Nginx начал в 2002 году Игорь Сысоев для Rambler. А в 2004 году он стал доступен широкому кругу пользователей . С 2011 года серверное ПО начала выпускать уже собственная фирма Игоря, которая спустя 2 года запустила расширенную платную версию продукта (Nginx Plus). Весной 2019 года Nginx была выкуплена крупным американским девелопером F5 Networks.
Nginx работает на ОС Unix-типа и был успешно протестирован на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На ОС Windows он стал доступен после выпуска бинарной сборки 0,7.52.
На данный момент функционалом пользуются такие известные платформы: Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru. Статистика показывает, что Nginx используют 22,3 млн веб-сайтов и 2,03 млн дополнительных активных сайтов.
