В последнее время я сталкиваюсь со все большим количеством сценариев, где необходимо настроить обратный прокси.Когда я создаю свой собственный блог, использование Nginx неизбежно, поэтому в это время я сосредоточился на изучении Nginx, и в то же время сделал некоторые заметки, Я надеюсь, что это также может помочь всем~ 😜
В этой статье мы установим и будем использовать Nginx в среде CentOS.Если вам непонятны основные операции CentOS, вы можете сначала взглянуть.Поймите сначала.
Я считаю, что как разработчик все знают о важности Nginx, давайте не будем нести чушь, давайте учиться вместе.
Версия CentOS:7.6
Версия Nginx:1.16.1
1. Введение в Nginx
В традиционных веб-серверах каждое клиентское подключение обрабатывается как отдельный процесс или поток.При переключении задач ЦП необходимо переключать на новую задачу, и создается новый контекст выполнения, потребляющий дополнительную память и время ЦП.Когда количество запросов увеличивается, сервер медленно отвечает, что отрицательно сказывается на производительности.
Nginx — это высокопроизводительный, высоконадежный веб- и обратный прокси-сервер с открытым исходным кодом, поддерживающий горячее развертывание, он может работать почти 7*24 часа в сутки, даже если он работает несколько месяцев, его не нужно перезапускать, и его можно использовать без перерыва. В случае обслуживания, горячее обновление версии программного обеспечения. Производительность является наиболее важным фактором для Nginx. Он занимает меньше памяти, обладает мощными возможностями параллелизма и может поддерживать одновременные соединения до 5 Вт. Самое главное, Nginx бесплатен и может быть коммерциализирован, а его настройка и использование относительно просты.
Наиболее важные сценарии использования Nginx:
- Служба статических ресурсов, предоставляющая услуги через локальную файловую систему;
- Служба обратного прокси, расширяющая в том числе кэширование, балансировку нагрузки и т.д.;
- API-сервис, OpenResty;
Node.js не новичок во внешнем интерфейсе, Nginx и Node.js имеют много схожих концепций, таких как HTTP-сервер, управление событиями, асинхронная неблокировка и т. д., и большинство функций Nginx также могут быть реализованы. используя Node.js, но Nginx и Node..js не конфликтуют, у каждого свои области знаний. Nginx хорошо справляется с низкоуровневыми серверными ресурсами (обработка и пересылка статических ресурсов, обратный прокси-сервер, балансировка нагрузки и т. д.), а Node.js лучше справляется с бизнес-логикой верхнего уровня. Эти два компонента можно идеально сочетать. чтобы совместно помочь фронтенд-разработке.
Давайте сосредоточимся на изучении использования Nginx.
2. Родственные понятия
2.1 Простые и непростые запросы
Во-первых, давайте рассмотрим простые запросы и непростые запросы.Если следующие два условия выполняются одновременно, это простой запрос:
- Метод запроса
HEAD
,GET
,POST
один из трех; - Информация заголовка HTTP не превышает нескольких полей справа:
Accept
,Accept-Language
,Content-Language
,Last-Event-ID
Content-Type
ограничено тремя значениямиapplication/x-www-form-urlencoded
,multipart/form-data
,text/plain
;
Все, что не соответствует этим двум условиям одновременно, является непростым запросом.
Браузеры по-разному обрабатывают простые и непростые запросы:
простой запрос
Для простого запроса браузер увеличит информацию в заголовкеOrigin
Непосредственно выдается после поля,Origin
Поле используется для указания источника (протокол + доменное имя + порт), из которого пришел этот запрос.
Если сервер находитOrigin
Если указанный источник не находится в допустимом диапазоне, сервер вернет обычный HTTP-ответ.После того, как браузер получит ответ, он обнаружит, что информация заголовка ответа не содержитAccess-Control-Allow-Origin
поле, он выдает ошибку в XHRerror
мероприятие;
Если сервер находитOrigin
Если указанное доменное имя находится в допустимом диапазоне, сервер вернет еще несколько ответов.Access-Control-
поля заголовка в начале.
не простой запрос
Непростой запрос — это запрос, который имеет особые требования к серверу. Например, метод запросаPUT
илиDELETE
,илиContent-Type
значениеapplication/json
. Браузер отправит HTTP Preview до официальной связи.OPTIONS
Запросите, сначала спросите сервер, находится ли доменное имя текущей страницы в списке разрешений сервера, и какие методы HTTP-запроса и поля заголовка можно использовать. Только при утвердительном ответе браузер выдаст официальноеXHR
запроса, иначе будет сообщено об ошибке.
2.2 Междоменный
Процесс отправки запроса на другой веб-сайт для получения данных с посещаемого в данный момент веб-сайта в браузеремеждоменный запрос.
Кроссдоменный браузерТа же политика происхожденияОпределено, является важной политикой безопасности браузера, которая ограничиваетoriginДокумент или скрипт, который он загружает, взаимодействует с ресурсами другого источника, это может помочь заблокировать вредоносные документы и уменьшить возможный вектор атаки, вы можете использоватьCORSКонфигурация снимает это ограничение.
Было много объяснений по поводу междоменного Интернета, поэтому я не буду здесь вдаваться в подробности, вы также можете напрямую прочитать MDN.Для дальнейшего понимания документа, вот несколько примеров гомологии и различных метаданных, которые, я думаю, понятны программистам.
# 同源的例子
http://example.com/app1/index.html # 只是路径不同
http://example.com/app2/index.html
http://Example.com:80 # 只是大小写差异
http://example.com
# 不同源的例子
http://example.com/app1 # 协议不同
https://example.com/app2
http://example.com # host 不同
http://www.example.com
http://myapp.example.com
http://example.com # 端口不同
http://example.com:8080
2.3 Прямой прокси и обратный прокси
Обратный прокси (Reverse Proxy) соответствует прямому прокси (Forward Proxy), их отличия:
Прокси вперед:Процесс общего доступа заключается в том, что клиент напрямую отправляет запрос на целевой сервер и получает контент.После использования прямого прокси клиент отправляет запрос на прокси-сервер и указывает целевой сервер (исходный сервер), а затем прокси сервер связывается с исходным сервером, перенаправляет запрос и получает контент, а затем возвращает его клиенту. Прямой прокси скрывает реального клиента, отправляет и получает запросы от клиента и делает настоящего клиента невидимым для сервера;
Чтобы привести конкретный пример 🌰, ваш браузер не может получить прямой доступ к Google Brother.В настоящее время вы можете использовать прокси-сервер, чтобы помочь вам получить доступ к Google Brother, тогда этот сервер называется прямым прокси.
Обратный прокси:По сравнению с процессом общего доступа, после использования обратного прокси-сервера сервер, который напрямую получает запрос, является прокси-сервером, а затем перенаправляет запрос на сервер фактической обработки во внутренней сети, а полученный результат возвращается клиенту. Обратный прокси скрывает реальный сервер, отправляет и получает запросы на сервер и делает настоящий сервер невидимым для клиента. Обычно он используется при работе с междоменными запросами. Сейчас практически все крупные сайты используют обратные прокси.
Чтобы привести конкретный пример🌰, когда вы идете в ресторан на ужин, вы можете заказать сычуаньскую, кантонскую, цзянсуйскую и чжэцзянскую кухню.В ресторане также есть три повара в трех кухнях.То есть Сяо Эр назначает блюда в вашем меню на различные повара для конкретной обработки, то этот Сяо Эр является обратным прокси-сервером.
Проще говоря, прямой прокси-сервер обычно используется в качестве прокси-сервера для клиента, а обратный прокси-сервер используется в качестве прокси-сервера для сервера.
Основное принципиальное различие между прямым прокси и обратным прокси можно увидеть на следующем рисунке:
2.4 Балансировка нагрузки
Как правило, клиент отправляет несколько запросов на сервер, сервер обрабатывает запросы, и некоторым из них может потребоваться работа с некоторыми ресурсами, такими как базы данных, статические ресурсы и т. д. После завершения обработки сервером результаты возвращаются клиенту. .
Для ранних систем эта модель предъявляла несложные функциональные требования и могла работать с относительно небольшим числом одновременных запросов, а стоимость также была низкой. Поскольку объем информации продолжает расти, объем доступа и данных быстро растет, а сложность системного бизнеса продолжает расти, этот подход больше не может соответствовать требованиям.Когда параллелизм особенно велик, сервер подвержен краху .
Очевидно, что это проблема, вызванная узким местом в производительности сервера.Помимо машины с кучей, самое главное - это балансировка нагрузки.
В случае взрывного роста запросов производительность одной машины не может удовлетворить требованиям, какой бы сильной она ни была.В это время возникла концепция кластеризации.Для задач, которые не могут быть решены одним сервером, можно использовать серверы, а затем запросы распределяются по каждому серверу, нагрузка распределяется по разным серверам, этоБалансировка нагрузки, ядро "разделяет давление". Nginx реализует балансировку нагрузки, которая обычно относится к переадресации запросов на кластеры серверов.
Приведу конкретный пример🌰, когда вы едете в метро в вечерний час пик, у входа на станцию часто будут громко говорить сотрудники метро "пожалуйста, пройдите к выходу B, там мало людей и пустые вагоны.... " Роль этого персонала заключается в балансировке нагрузки.
2.5 Динамическое и статическое разделение
Чтобы ускорить анализ веб-сайта, динамические страницы и статические страницы могут анализироваться разными серверами, чтобы увеличить скорость анализа и снизить нагрузку на исходный отдельный сервер.
Вообще говоря, необходимо отделить динамические ресурсы от статических ресурсов.Из-за высокой параллелизма Nginx и кэширования статических ресурсов статические ресурсы часто развертываются на Nginx. Если запрос относится к статическим ресурсам, перейдите непосредственно в каталог статических ресурсов для получения ресурсов.Если запрос относится к динамическим ресурсам, используется принцип обратного прокси-сервера для пересылки запроса соответствующему фоновому приложению для обработки, тем самым реализуя динамические и статическое разделение.
После разделения внешнего и внутреннего интерфейса скорость доступа к статическим ресурсам может быть значительно улучшена.Даже если динамические службы недоступны, доступ к статическим ресурсам не пострадает.
3. Быстрая установка Nginx
3.1 Установка
мы можем видеть первыми
yum list | grep nginx
приди и посмотри
потом
yum install nginx
установить Nginx, то мы в командной строкеnginx -v
Вы можете увидеть конкретную информацию о версии Nginx, и установка завершена.
3.2 соответствующую папку
Тогда мы можем использоватьrpm -ql nginx
Чтобы увидеть, где установлен Nginx и какие связанные каталоги расположены в/etc
В каталоге в основном находятся файлы конфигурации, и некоторые файлы показаны на следующем рисунке:
Есть две папки, представляющие наибольший интерес:
-
/etc/nginx/conf.d/
Папка — это место, где мы храним элементы конфигурации для подконфигурации./etc/nginx/nginx.conf
Основной файл конфигурации по умолчанию импортирует все элементы вложенной конфигурации в эту папку; -
/usr/share/nginx/html/
Папка, обычно статические файлы помещаются в эту папку или в другие места по вашим привычкам;
3.3 Беги здоровым
После установки откройте Nginx. Если в системе включен брандмауэр, вам необходимо установить порты, которые необходимо открыть в брандмауэре. Вот несколько общих операций с брандмауэром (не беспокойтесь об этом, если он не включен) :
systemctl start firewalld # 开启防火墙
systemctl stop firewalld # 关闭防火墙
systemctl status firewalld # 查看防火墙开启状态,显示running则是正在运行
firewall-cmd --reload # 重启防火墙,永久打开端口需要reload一下
# 添加开启端口,--permanent表示永久打开,不加是临时打开重启之后失效
firewall-cmd --permanent --zone=public --add-port=8888/tcp
# 查看防火墙,添加的端口也可以看到
firewall-cmd --list-all
Затем установите запуск Nginx:
systemctl enable nginx
Запустите Nginx (другие команды подробно описаны ниже):
systemctl start nginx
Затем посетите свой IP-адрес, после чего вы увидите страницу приветствия Nginx~Welcome to nginx!
👏
3.4 Установите nvm, узел и git
# 下载 nvm,或者看官网的步骤 https://github.com/nvm-sh/nvm#install--update-script
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
source ~/.bashrc # 安装完毕后,更新配置文件即可使用 nvm 命令
nvm ls-remote # 查看远程 node 版本
nvm install v12.16.3 # 选一个你要安装的版本安装,我这里选择 12.16.3
nvm list # 安装完毕查看安装的 node 版本
node -v # 查看是否安装好了
yum install git # git 安装
4. Общие команды работы Nginx
Команды Nginx вводятся в консолиnginx -h
Вы можете увидеть полную команду, вот несколько часто используемых команд:
nginx -s reload # 向主进程发送信号,重新加载配置文件,热重启
nginx -s reopen # 重启 Nginx
nginx -s stop # 快速关闭
nginx -s quit # 等待工作进程处理完成后关闭
nginx -T # 查看当前 Nginx 最终的配置
nginx -t -c <配置路径> # 检查配置是否有问题,如果已经在配置目录,则不需要-c
systemctl
это инструмент управления системными приложениями Linuxsystemd
Основная команда используется для управления системой, и мы также можем использовать ее для управления Nginx, Соответствующие команды следующие:
systemctl start nginx # 启动 Nginx
systemctl stop nginx # 停止 Nginx
systemctl restart nginx # 重启 Nginx
systemctl reload nginx # 重新加载 Nginx,用于修改配置后
systemctl enable nginx # 设置开机启动 Nginx
systemctl disable nginx # 关闭开机启动 Nginx
systemctl status nginx # 查看 Nginx 运行状态
5. Синтаксис конфигурации Nginx
Как показано на рисунке, объясняющем функцию предыдущего файла, основным файлом конфигурации Nginx является/etc/nginx/nginx.conf
,вы можете использоватьcat -n nginx.conf
для просмотра конфигурации.
nginx.conf
Структурную схему можно представить следующим образом:
main # 全局配置,对全局生效
├── events # 配置影响 Nginx 服务器或与用户的网络连接
├── http # 配置代理,缓存,日志定义等绝大多数功能和第三方模块的配置
│ ├── upstream # 配置后端服务器具体地址,负载均衡配置不可或缺的部分
│ ├── server # 配置虚拟主机的相关参数,一个 http 块中可以有多个 server 块
│ ├── server
│ │ ├── location # server 块可以包含多个 location 块,location 指令用于匹配 uri
│ │ ├── location
│ │ └── ...
│ └── ...
└── ...
Файл конфигурации Nginx структурирован какnginx.conf
Как показано, правила синтаксиса для файла конфигурации:
- Файл конфигурации состоит из инструкций и блоков инструкций;
- Каждая инструкция начинается с
;
В конце точки с запятой команда и параметр разделяются пробелом; - блок команд с
{}
Скобки группируют несколько инструкций вместе; -
include
Заявления позволяют комбинировать несколько файлов конфигурации для улучшения удобства обслуживания; - использовать
#
Добавляйте комментарии к символам для улучшения читабельности; - использовать
$
символы используют переменные; - Параметры некоторых команд поддерживают регулярные выражения;
5.1 Типовая конфигурация
Типичная конфигурация для Nginx:
user nginx; # 运行用户,默认即是nginx,可以不进行设置
worker_processes 1; # Nginx 进程数,一般设置为和 CPU 核数一样
error_log /var/log/nginx/error.log warn; # Nginx 的错误日志存放目录
pid /var/run/nginx.pid; # Nginx 服务启动时的 pid 存放位置
events {
use epoll; # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法,会自动选择一个最适合你操作系统的)
worker_connections 1024; # 每个进程允许最大并发数
}
http { # 配置使用最频繁的部分,代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置
# 设置日志模式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main; # Nginx访问日志存放位置
sendfile on; # 开启高效传输模式
tcp_nopush on; # 减少网络报文段的数量
tcp_nodelay on;
keepalive_timeout 65; # 保持连接的时间,也叫超时时间,单位秒
types_hash_max_size 2048;
include /etc/nginx/mime.types; # 文件扩展名与类型映射表
default_type application/octet-stream; # 默认文件类型
include /etc/nginx/conf.d/*.conf; # 加载子配置项
server {
listen 80; # 配置监听的端口
server_name localhost; # 配置的域名
location / {
root /usr/share/nginx/html; # 网站根目录
index index.html index.htm; # 默认首页文件
deny 172.168.22.11; # 禁止访问的ip地址,可以为all
allow 172.168.33.44; # 允许访问的ip地址,可以为all
}
error_page 500 502 503 504 /50x.html; # 默认50x对应的访问页面
error_page 400 404 error.html; # 同上
}
}
Блок server может содержать несколько блоков location.Директива location используется для сопоставления с uri.Синтаксис:
location [ = | ~ | ~* | ^~] uri {
...
}
После команды:
-
=
Точный совпадающий путь, используемый перед uri без регулярного выражения, в случае успешного совпадения последующий поиск выполняться не будет; -
^~
Используется для uri без регулярного выражения, раньше означает, что если символ, следующий за символом, является наилучшим совпадением, это правило будет принято, и последующие поиски выполняться не будут; -
~
Указывает, что обычный шаблон позади символа используется для сопоставления пути с учетом регистра; -
~*
Указывает, что для сопоставления пути используется обычный шаблон, стоящий за символом, который не чувствителен к регистру. а также~
Приоритет относительно низкий.Если регулярные выражения нескольких местоположений могут совпадать, используется то, у которого регулярное выражение самое длинное;
Если uri содержит регулярные выражения, он должен иметь~
или~*
логотип.
5.2 Глобальные переменные
Nginx имеет несколько часто используемых глобальных переменных, вы можете использовать их в любом месте конфигурации, как показано в следующей таблице:
имя глобальной переменной | Функция |
---|---|
$host |
в запросеHost , если запрос неHost строка, она равна заданному имени сервера, исключая порт |
$request_method |
тип запроса клиента, напримерGET ,POST
|
$remote_addr |
клиентаIP адрес |
$args |
параметры в запросе |
$arg_PARAMETER |
GET Значение параметра PARAMETER имени переменной в запросе, например:$http_user_agent (значение User-Agent),$http_referer ... |
$content_length |
в заголовке запросаContent-length поле |
$http_user_agent |
Информация об агенте клиента |
$http_cookie |
Информация о файлах cookie клиента |
$remote_addr |
IP-адрес клиента |
$remote_port |
клиентский порт |
$http_user_agent |
Информация об агенте клиента |
$server_protocol |
Протокол, используемый запросом, напримерHTTP/1.0 ,HTTP/1.1
|
$server_addr |
адрес сервера |
$server_name |
псевдоним сервера |
$server_port |
номер порта сервера |
$scheme |
Метод HTTP (например, http, https) |
Есть больше встроенных предопределенных переменных, вы можете напрямую искать по ключевому слову «встроенные предопределенные переменные nginx», вы можете увидеть множество блогов, которые пишут об этом, эти переменные можно использовать непосредственно в файле конфигурации.
6. Настройте виртуальный хост вторичного доменного имени.
После покупки доменного имени на XX Cloud ☁️ вы можете настроить виртуальный хост.Общий путь конфигурации находится в域名管理 -> 解析 -> 添加记录
После настройки некое облако также будет разрешать доменное имя второго уровня в настроенный нами IP сервера, а затем мы настроим мониторинг доступа виртуального хоста на Nginx, и тогда мы сможем получить доменное имя второго уровня из этого доменное имя второго уровня.
Сейчас я настроил доменное имя второго уровня fe на собственном сервере, то есть к нему можно получить доступ из внешней сети.fe.sherlocked93.club
, вы также можете получить доступ к нашему серверу.
Из-за файла конфигурации по умолчанию/etc/nginx/nginx.conf
В модуле http есть предложениеinclude /etc/nginx/conf.d/*.conf
то естьconf.d
Вся папка*.conf
Файлы импортируются в файл конфигурации как элементы подконфигурации. Для удобства обслуживания я/etc/nginx/conf.d
создать новую папкуfe.sherlocked93.club.conf
:
# /etc/nginx/conf.d/fe.sherlocked93.club.conf
server {
listen 80;
server_name fe.sherlocked93.club;
location / {
root /usr/share/nginx/html/fe;
index index.html;
}
}
затем в/usr/share/nginx/html
Создайте новую папку fe в папке и создайте новый файлindex.html
, просто напишите содержимое и измените егоnginx -s reload
Перезагрузить, ввести в браузереfe.sherlocked93.club
, и обнаружили, что к только что созданной папке fe можно получить доступ с доменного имени второго уровня:
7. Настройте обратный прокси
Обратный прокси — наиболее часто используемая функция сервера в работе, и часто используется для решения междоменных проблем.Нижеследующее кратко описывает, как реализовать обратный прокси.
Сначала введите основной файл конфигурации Nginx:
vim /etc/nginx/nginx.conf
Показать номера строк для удобства:set nu
(личная привычка), то идемhttp
модульныйserver
в блокеlocation /
, добавьте строку для перенаправления URL-адреса по умолчанию на крупнейший учебный сайт Bilibili.proxy_pass
Настроить 🤓 :
Сохраните и выйдите после внесения изменений.nginx -s reload
Перезагрузите, введите URL-адрес по умолчанию, затем перейдите непосредственно к станции B и внедрите простой прокси.
При фактическом использовании запрос может быть перенаправлен на другой сервер на локальном компьютере или может быть передан службе на другом порту в соответствии с путем доступа.
Например, мы мониторим9001
порт, а затем обратные прокси-запросы для доступа к разным путям:
- поставить доступ
http://127.0.0.1:9001/edu
запросы направляются наhttp://127.0.0.1:8080
- поставить доступ
http://127.0.0.1:9001/vod
запросы направляются наhttp://127.0.0.1:8081
Как это настроить, сначала откройте основной файл конфигурации, а затем добавьте блок сервера под модулем http:
server {
listen 9001;
server_name *.sherlocked93.club;
location ~ /edu/ {
proxy_pass http://127.0.0.1:8080;
}
location ~ /vod/ {
proxy_pass http://127.0.0.1:8081;
}
}
У обратного прокси есть и другие инструкции, о них вы можете узнать:
-
proxy_set_header
: измените информацию заголовка запроса от клиента перед отправкой запроса клиента на внутренний сервер. -
proxy_connect_timeout
: Настройте период ожидания для Nginx, чтобы попытаться установить соединение с внутренним прокси-сервером. -
proxy_read_timeout
: настроить Nginx на ожидание соответствующего тайм-аута после отправки запроса на чтение в группу внутренних серверов. -
proxy_send_timeout
: настроить Nginx на ожидание соответствующего тайм-аута после отправки запроса на запись в группу внутренних серверов. -
proxy_redirect
: используется для изменения местоположения и обновления в заголовке ответа, возвращаемом внутренним сервером.
8. Междоменная конфигурация CORS
Концепции простых запросов, не простой запрос и кросс-домен были представлены ранее. Если вы этого не понимаете, вы можете прочитать предыдущее объяснение. Теперь передние и задневские разделяющиеся проекты доминируют в мире. ФОНД-КОНЕЧНЫЕ СЛУЖБЫ часто запускаются локально, и необходимо доступен разные задние адресованные адреса, которые неизбежно соответствуют проблемам с перекрестным домом.
Чтобы решить междоменную проблему, давайте создадим междоменную проблему. Прежде всего, так же, как и предыдущая настройка доменного имени второго уровня, сначала настройте его.fe.sherlocked93.club
а такжеbe.sherlocked93.club
Все доменные имена второго уровня указывают на адрес облачного сервера, хотя соответствующий IP-адрес один и тот же, но вfe.sherlocked93.club
Запросить доступ с доменного имениbe.sherlocked93.club
Запрос имени домена по-прежнему является междоменным, поскольку хосты, к которым осуществляется доступ, несовместимы (если вы не знаете причину, см. предыдущий междоменный контент).
8.1 Используйте обратный прокси-сервер для разрешения междоменных
В интерфейсном сервисном адресеfe.sherlocked93.club
Запрос страницыbe.sherlocked93.club
Междоменное взаимодействие, вызванное серверной службой , можно настроить следующим образом:
server {
listen 9001;
server_name fe.sherlocked93.club;
location / {
proxy_pass be.sherlocked93.club;
}
}
Это изменит предыдущее доменное имяfe.sherlocked93.club
все запросы проксируютсяbe.sherlocked93.club
, внешние запросы проксируются нашим сервером на внутренний адрес, минуя междоменные.
Здесь запросы к статическим файлам и внутренним службам начинаются сfe.sherlocked93.club
В начале это нелегко отличить, поэтому для достижения унифицированной переадресации внутренних запросов на обслуживание мы обычно соглашаемся добавлять запросы на внутренние службы в/apis/
Префикс или другой путь и различать статические ресурсы, мы можем настроить это:
# 请求跨域,约定代理后端服务请求path以/apis/开头
location ^~/apis/ {
# 这里重写了请求,将正则匹配中的第一个分组的path拼接到真正的请求后面,并用break停止后续匹配
rewrite ^/apis/(.*)$ /$1 break;
proxy_pass be.sherlocked93.club;
# 两个域名之间cookie的传递与回写
proxy_cookie_domain be.sherlocked93.club fe.sherlocked93.club;
}
Таким образом, статические ресурсы, которые мы используемfe.sherlocked93.club/xx.html
, динамические ресурсы, которые мы используемfe.sherlocked93.club/apis/getAwo
, страница браузера по-прежнему обращается к интерфейсному серверу в обход политики браузера в отношении одного и того же источника, в конце концов, похоже, мы не являемся междоменными.
Также возможно унифицировать и напрямую перенаправить адреса внешнего и внутреннего серверов на другой сервер.server.sherlocked93.club
, только по пути, добавленному позже, чтобы определить, является ли запрос статическим ресурсом или серверной службой, в зависимости от спроса.
8.2 Настройка заголовков для разрешения перекрестного домена
Когда браузер обращается к кросс-оригинальному серверу, он также может установить Nginx прямо на кросс-доменный сервер, чтобы фронтенд можно было разрабатывать не чувствуя, не меняя адрес фактического доступа к бэкенду на адрес фронтенд-сервиса, который можно адаптировать под Секс выше.
Например, интерфейсный сайтfe.sherlocked93.club
, запрос страницы интерфейса по этому адресуbe.sherlocked93.club
ресурсы ниже, такие как бывшийfe.sherlocked93.club/index.html
Содержание таково:
<html>
<body>
<h1>welcome fe.sherlocked93.club!!<h1>
<script type='text/javascript'>
var xmlhttp = new XMLHttpRequest()
xmlhttp.open("GET", "http://be.sherlocked93.club/index.html", true);
xmlhttp.send();
</script>
</body>
</html>
Открытый доступ в браузереfe.sherlocked93.club/index.html
Результат выглядит следующим образом:
Очевидно, что это перекрестный домен, непосредственно доступ в браузереhttp://be.sherlocked93.club/index.html
доступен, но вfe.sherlocked93.club
Доступ к html-странице будет выглядеть междоменным.
существует/etc/nginx/conf.d/
Создайте новый конфигурационный файл в папке, соответствующей доменному имени второго уровняbe.sherlocked93.club
:
# /etc/nginx/conf.d/be.sherlocked93.club.conf
server {
listen 80;
server_name be.sherlocked93.club;
add_header 'Access-Control-Allow-Origin' $http_origin; # 全局变量获得当前请求origin,带cookie的请求不支持*
add_header 'Access-Control-Allow-Credentials' 'true'; # 为 true 可带上 cookie
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; # 允许请求方法
add_header 'Access-Control-Allow-Headers' $http_access_control_request_headers; # 允许请求的 header,可以为 *
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Max-Age' 1728000; # OPTIONS 请求的有效期,在有效期内不用发出另一条预检请求
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204; # 200 也可以
}
location / {
root /usr/share/nginx/html/be;
index index.html;
}
}
потомnginx -s reload
Перезагрузить конфигурацию. посетить сноваfe.sherlocked93.club/index.html
В результате в запросе появляется только что настроенный заголовок:
Решены междоменные проблемы.
9. Включите сжатие gzip
Gzip является широко используемой технологией сжатия веб-страниц. Размер передаваемой веб-страницы после сжатия gzip обычно может уменьшиться вдвое или даже меньше (исходные слова официального сайта). Меньший размер веб-страницы также означает экономию полосы пропускания и скорость передачи. улучшение, особенно для масштабных веб-сайтов с огромным трафиком, уменьшает объем каждого статического ресурса, что приведет к значительной экономии трафика и полосы пропускания.
Baidu может найти множество сайтов обнаружения, чтобы проверить, включено ли сжатие gzip на целевой веб-странице, и я нашел один наугад.Введите самородкиjuejin.im
Давайте посмотрим, включили ли наггетты на GZIP.
Здесь видно, что Nuggets включили gzip, и эффект сжатия весьма неплох, достигая целых 52%.34kb
Объем веб-страницы после сжатия нужен только16kb
, вполне возможно, что скорость передачи веб-страниц значительно улучшилась.
9.1 Настройка gzip в Nginx
Использование gzip требует не только настройки Nginx, но и взаимодействия со стороны браузера, что необходимо включить в заголовок запроса.Accept-Encoding: gzip
(Все браузеры после IE5 поддерживают его, и это настройка по умолчанию для современных браузеров). Как правило, при запросе статических ресурсов, таких как html и css, поддерживаемые браузеры добавляютAccept-Encoding: gzip
Этот заголовок указывает на то, что он поддерживает метод сжатия gzip.Когда Nginx получит запрос, если он имеет соответствующую конфигурацию, он вернет gzip-файл в браузер и добавит его в ответ.content-encoding: gzip
Чтобы сообщить браузеру метод сжатия, который он использует (поскольку браузер обычно сообщает серверу, что он поддерживает несколько методов сжатия при передаче файла на сервер), после того, как браузер получает сжатый файл, он анализирует его в соответствии со своим собственным методом распаковки.
Давайте сначала посмотрим, как Nginx выполняет настройку gzip.Как и предыдущая конфигурация, для удобства управления она все еще находится в/etc/nginx/conf.d/
Создайте новый файл конфигурации в папкеgzip.conf
:
# /etc/nginx/conf.d/gzip.conf
gzip on; # 默认off,是否开启gzip
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
# 上面两个开启基本就能跑起了,下面的愿意折腾就了解一下
gzip_static on;
gzip_proxied any;
gzip_vary on;
gzip_comp_level 6;
gzip_buffers 16 8k;
# gzip_min_length 1k;
gzip_http_version 1.1;
Чтобы немного объяснить:
- gzip_types: тип файла MIME для сжатия с помощью gzip, где text/html применяется системой;
-
gzip_static: выключено по умолчанию, после включения этого модуля Nginx сначала проверяет, есть ли файл, оканчивающийся на gz, который запрашивает статический файл, и возвращает файл напрямую, если он есть.
.gz
содержание документа; - gzip_proxied: выключено по умолчанию, включено, когда nginx используется в качестве обратного прокси, используется для включения или отключения сжатия gzip соответствующего контента, полученного от прокси-сервера;
-
gzip_vary: используется для добавления в заголовок ответа
Vary:Accept-Encoding
, чтобы прокси-сервер согласно заголовку запросаAccept-Encoding
Определите, включено ли сжатие gzip; - gzip_comp_level: степень сжатия gzip, уровень сжатия 1-9, 1 — самый низкий уровень сжатия, 9 — самый высокий, чем выше уровень, тем больше степень сжатия и дольше время сжатия, рекомендуется 4-6;
- gzip_buffers: Сколько памяти нужно получить для кеширования результатов сжатия, 16 8k означает получить в единицах 8k*16;
-
gzip_min_length: Минимальное количество байт, допустимое для сжатия страницы, количество байтов страницы находится из заголовка в заголовке.
Content-Length
получено в. Значение по умолчанию — 0, что означает сжатие независимо от размера страницы. Рекомендуется ставить количество байт больше 1к, если меньше 1к, то может увеличиться давление; - gzip_http_version: по умолчанию 1.1, минимальная версия HTTP, необходимая для включения gzip;
Эту конфигурацию можно вставить в конфигурацию http-модуля всего сервера или в виртуальный хост, который необходимо использовать.server
или следующееlocation
В модуле, естественно, то, что мы написали выше, включено в модуль http.
Другую более полную информацию о конфигурации можно посмотреть, перед конфигурацией так:
После настройки в ответ приходит еще один заголовокContent-Encoding: gzip
, возвращаемая информация сжимается:
Обратите внимание, что в общую конфигурацию gzip рекомендуется добавитьgzip_min_length 1k
, без добавления:
Поскольку файл слишком мал, после сжатия gzip объем оптимизируется на -48%, а объем после сжатия все еще больше, чем до сжатия, поэтому лучше установить его ниже1kb
Не сжимайте файлы 🤪
9.2 Конфигурация веб-пакета gzip
Когда интерфейсный проект упакован с помощью Webpack, также можно включить сжатие gzip:
// vue-cli3 的 vue.config.js 文件
const CompressionWebpackPlugin = require('compression-webpack-plugin')
module.exports = {
// gzip 配置
configureWebpack: config => {
if (process.env.NODE_ENV === 'production') {
// 生产环境
return {
plugins: [new CompressionWebpackPlugin({
test: /\.js$|\.html$|\.css/, // 匹配文件名
threshold: 10240, // 文件压缩阈值,对超过10k的进行压缩
deleteOriginalAssets: false // 是否删除源文件
})]
}
}
},
...
}
Упакованные файлы выглядят следующим образом:
Здесь вы можете увидеть, что некоторые из упакованных файлов имеют соответствующие.gz
проходить черезgzip
Сжатый файл, потому что размер файла превышает10kb
, некоторые файлы не превышают10kb
не продолжилgzip
Упаковка, если вы ожидаете, что порог размера сжатого файла будет меньше, вы можетеcompression-webpack-plugin
Конфигурация этого плагина настроена соответствующим образом.
Так почему же у Nginx здесь уже есть gzip-сжатие, а у Webpack здесь есть целый gzip, ведь если все используют Nginx для сжатия файлов, он будет потреблять вычислительные ресурсы сервера, если серверgzip_comp_level
Чем выше конфигурация, тем больше будут увеличены накладные расходы сервера, и соответственно возрастет время запроса клиента, что не стоит потерь.
Если действие сжатия выполняется, когда внешний интерфейс упакован, а упакованные файлы с высоким уровнем сжатия размещаются на сервере как статические ресурсы, Nginx сначала будет искать эти сжатые файлы и возвращать их клиенту, что эквивалентно Действие сжатия файлов завершается, когда Nginx заранее упаковывает Webpack, что экономит ресурсы сервера, поэтому обычно рекомендуется применять Webpack для настройки сжатия gzip в производственной среде.
10. Настройте балансировку нагрузки
Концепция балансировки нагрузки была введена ранее.Основная идея состоит в том, чтобы равномерно и разумно распределить нагрузку на несколько серверов для достижения цели распределения нагрузки.
Основная конфигурация выглядит следующим образом:
http {
upstream myserver {
# ip_hash; # ip_hash 方式
# fair; # fair 方式
server 127.0.0.1:8081; # 负载均衡目的服务地址
server 127.0.0.1:8080;
server 127.0.0.1:8082 weight=10; # weight 方式,不写默认为 1
}
server {
location / {
proxy_pass http://myserver;
proxy_connect_timeout 10;
}
}
}
Nginx предоставляет несколько методов выделения, по умолчаниюголосование, это по очереди. Существуют следующие способы распространения:
- голосование, по умолчанию каждый запрос распределяется по разным back-end серверам в хронологическом порядке, если back-end сервис зависает, его можно устранить автоматически;
- weight, распределение веса, указать вероятность опроса, чем больше вес, тем больше вероятность обращения, что используется в случае неравномерной производительности внутреннего сервера;
- ip_hash, каждый запрос распределяется в соответствии с результатом хэширования IP-адреса доступа, поэтому каждый посетитель может получить фиксированный доступ к внутреннему серверу, что может решить проблему динамического совместного использования сеансов веб-страницы. Каждый запрос на балансировку нагрузки будет перемещаться на один из серверных кластеров.Если пользователь, вошедший на определенный сервер, будет перемещен на другой сервер, то его данные для входа будут утеряны, что явно нецелесообразно;
- fair(Сторонний), выделяется по времени отклика внутреннего сервера, а тот, у которого короткое время отклика, будет выделяться первым, опираясь на сторонний плагин nginx-upstream-fair, который необходимо установить первый;
11. Настройте динамическое и статическое разделение
Ранее также было введено разделение динамических и статических запросов, которое заключается в разделении динамических и статических запросов. Есть два основных способа: один — просто разделить статические файлы на отдельные доменные имена и разместить их на отдельных серверах, что также является распространенным решением в настоящее время. Другой способ — смешивать и распространять динамические и статические файлы, разделенные конфигурацией Nginx.
Различная переадресация запросов может быть достигнута путем указания разных имен суффиксов через местоположение. Установив параметр expires, вы можете сделать время истечения срока действия кеша браузера и уменьшить запрос и трафик перед сервером. Конкретное определение срока действия: это установка времени истечения срока действия ресурса, то есть ему не нужно отправляться на сервер для проверки, и он может напрямую подтвердить, истекает ли срок его действия через сам браузер, поэтому никаких дополнительных трафик будет генерироваться. Этот подход идеален для ресурсов, которые изменяются нечасто. (Если файл часто обновляется, не рекомендуется использовать expires для кеша), здесь я ставлю 3d, что означает, что в течение этих 3-х дней зайти на этот URL, отправить запрос и сравнить сервер с последним временем обновления файл не изменился. Он не будет получен с сервера, и будет возвращен код состояния 304. Если есть какое-либо изменение, оно будет загружено непосредственно с сервера, и будет возвращен код состояния 200.
server {
location /www/ {
root /data/;
index index.html index.htm;
}
location /image/ {
root /data/;
autoindex on;
}
}
12. Настройте кластер высокой доступности (горячий резерв с двумя системами)
Когда основной сервер Nginx выйдет из строя, переключитесь на резервный сервер Nginx.
Сначала установите keepalived,
yum install keepalived -y
затем отредактируйте/etc/keepalived/keepalived.conf
конфигурационный файл и добавить в конфигурационный файлvrrp_script
определить механизм периферийного обнаружения иvrrp_instance
по определениюtrack_script
Чтобы отследить процесс выполнения скрипта и осуществить перенос ноды:
global_defs{
notification_email {
acassen@firewall.loc
}
notification_email_from Alexandre@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30 // 上面都是邮件配置,没卵用
router_id LVS_DEVEL // 当前服务器名字,用hostname命令来查看
}
vrrp_script chk_maintainace { // 检测机制的脚本名称为chk_maintainace
script "[[ -e/etc/keepalived/down ]] && exit 1 || exit 0" // 可以是脚本路径或脚本命令
// script "/etc/keepalived/nginx_check.sh" // 比如这样的脚本路径
interval 2 // 每隔2秒检测一次
weight -20 // 当脚本执行成立,那么把当前服务器优先级改为-20
}
vrrp_instanceVI_1 { // 每一个vrrp_instance就是定义一个虚拟路由器
state MASTER // 主机为MASTER,备用机为BACKUP
interface eth0 // 网卡名字,可以从ifconfig中查找
virtual_router_id 51 // 虚拟路由的id号,一般小于255,主备机id需要一样
priority 100 // 优先级,master的优先级比backup的大
advert_int 1 // 默认心跳间隔
authentication { // 认证机制
auth_type PASS
auth_pass 1111 // 密码
}
virtual_ipaddress { // 虚拟地址vip
172.16.2.8
}
}
который обнаруживает скриптnginx_check.sh
, вот один:
#!/bin/bash
A=`ps -C nginx --no-header | wc -l`
if [ $A -eq 0 ];then
/usr/sbin/nginx # 尝试重新启动nginx
sleep 2 # 睡眠2秒
if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then
killall keepalived # 启动失败,将keepalived服务杀死。将vip漂移到其它备份节点
fi
fi
Скопируйте копию на резервный сервер, и конфигурация резервного Nginx должна бытьstate
позже изменился наBACKUP
,priority
Изменено, чтобы быть меньше, чем хост.
После настройки каждогоservice keepalived start
Запустите, после успешного доступа вы можете остановить поддержку активности главной машины, и главная машина больше не является хостом в это время.service keepalived stop
, чтобы увидеть, может ли он автоматически переключаться на резервную машину при доступе к виртуальному IP-адресу.ip addr
.
Снова запустите keepalived мастера, и вип снова сменился на хост.
13. Адаптация к ПК или мобильному устройству
По разным устройствам пользователей возвращаются разные стили сайтов.Раньше часто использовалась чистая адаптивная верстка фронтенда, но она не так хороша, как раздельное написание по сложности и простоте использования, как наш общий Taobao, Jingdong.... .. Эти крупные веб-сайты не являются адаптивными, а создаются отдельно по запросу пользователя.user-agent
чтобы определить, следует ли вернуться на ПК или на сайт H5.
первый в/usr/share/nginx/html
в папкеmkdir
Создайте две новые папкиPC
а такжеmobile
,vim
изменить дваindex.html
Пишите все, что хотите.
cd /usr/share/nginx/html
mkdir pc mobile
cd pc
vim index.html # 随便写点比如 hello pc!
cd ../mobile
vim index.html # 随便写点比如 hello mobile!
Затем, как и при настройке виртуального хоста доменного имени второго уровня, перейдите на/etc/nginx/conf.d
Создайте новый файл конфигурации в папкеfe.sherlocked93.club.conf
:
# /etc/nginx/conf.d/fe.sherlocked93.club.conf
server {
listen 80;
server_name fe.sherlocked93.club;
location / {
root /usr/share/nginx/html/pc;
if ($http_user_agent ~* '(Android|webOS|iPhone|iPod|BlackBerry)') {
root /usr/share/nginx/html/mobile;
}
index index.html;
}
}
Конфигурация в основном такая же, в основном еще однаif
утверждение, затем используйте$http_user_agent
Глобальные переменные для определения запроса пользователяuser-agent
, указывая на другой корневой путь и возвращая соответствующий сайт.
Посетите этот сайт в браузере, а затем смоделируйте посещение с помощью мобильного телефона, нажав F12:
Видно, что при имитации доступа с мобильного терминала сайт, возвращаемый Nginx, становится соответствующим html на мобильном терминале.
14. Настройте HTTPS
В интернете довольно много специфических процедур настройки, а также вы можете использовать конкретное облако, которое вы приобрели.Бесплатное приложениеВы можете установить сертификат сервера напрямую, обратившись к руководству по эксплуатации облака, в котором вы находитесь.
Купленный мной бесплатный сертификат, выданный Asia Integrity Agency, предоставленный Tencent Cloud, можно использовать только для одного доменного имени, а доменное имя второго уровня нужно подавать отдельно.xxx.crt
а такжеxxx.key
Скопируйте файл в каталог сервера и настройте его:
server {
listen 443 ssl http2 default_server; # SSL 访问端口号为 443
server_name sherlocked93.club; # 填写绑定证书的域名
ssl_certificate /etc/nginx/https/1_sherlocked93.club_bundle.crt; # 证书文件地址
ssl_certificate_key /etc/nginx/https/2_sherlocked93.club.key; # 私钥文件地址
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #请按照以下协议配置
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
законченныйnginx -t -q
Проверьте это, это нормальноnginx -s reload
, теперь в гостиhttps://sherlocked93.club/
Вы можете получить доступ к HTTPS-версии веб-сайта.
В общем, можно добавить несколько дополнительных команд, повышающих безопасность:
add_header X-Frame-Options DENY; # 减少点击劫持
add_header X-Content-Type-Options nosniff; # 禁止服务器自动解析资源类型
add_header X-Xss-Protection 1; # 防XSS攻击
15. Некоторые общие приемы
15.1 статическая служба
server {
listen 80;
server_name static.sherlocked93.club;
charset utf-8; # 防止中文文件名乱码
location /download {
alias /usr/share/nginx/html/static; # 静态资源目录
autoindex on; # 开启静态资源列目录
autoindex_exact_size off; # on(默认)显示文件的确切大小,单位是byte;off显示文件大概大小,单位KB、MB、GB
autoindex_localtime off; # off(默认)时显示的文件时间为GMT时间;on显示的文件时间为服务器时间
}
}
15.2 Картинка против пиявки
server {
listen 80;
server_name *.sherlocked93.club;
# 图片防盗链
location ~* \.(gif|jpg|jpeg|png|bmp|swf)$ {
valid_referers none blocked server_names ~\.google\. ~\.baidu\. *.qq.com; # 只允许本机 IP 外链引用,感谢 @木法传 的提醒,将百度和谷歌也加入白名单
if ($invalid_referer){
return 403;
}
}
}
15.3 Фильтрация запросов
# 非指定请求全返回 403
if ( $request_method !~ ^(GET|POST|HEAD)$ ) {
return 403;
}
location / {
# IP访问限制(只允许IP是 192.168.0.2 机器访问)
allow 192.168.0.2;
deny all;
root html;
index index.html index.htm;
}
15.4 Настройка кэширования статических файлов, таких как изображения и шрифты
Поскольку к изображениям, шрифтам, аудио, видео и другим статическим файлам обычно добавляется хэш при их упаковке, кеш может быть установлен более длинным, сначала установить обязательный кеш, а затем установить кеш согласования; если есть статические файлы без хеш-значения, рекомендуется не устанавливать обязательный кеш, а определять, использовать ли кеш только путем согласования кеша.
# 图片缓存时间设置
location ~ .*\.(css|js|jpg|png|gif|swf|woff|woff2|eot|svg|ttf|otf|mp3|m4a|aac|txt)$ {
expires 10d;
}
# 如果不希望缓存
expires -1;
15.5 Настройка маршрутизации одностраничной истории проекта
server {
listen 80;
server_name fe.sherlocked93.club;
location / {
root /usr/share/nginx/html/dist; # vue 打包后的文件夹
index index.html index.htm;
try_files $uri $uri/ /index.html @rewrites;
expires -1; # 首页一般没有强制缓存
add_header Cache-Control no-cache;
}
# 接口转发,如果需要的话
#location ~ ^/api {
# proxy_pass http://be.sherlocked93.club;
#}
location @rewrites {
rewrite ^(.+)$ /index.html break;
}
}
15.6 Переадресация HTTP-запросов на HTTPS
После настройки HTTPS браузер все еще может получить доступ к адресу HTTPhttp://sherlocked93.club/
Да, вы можете выполнить перенаправление 301, чтобы перенаправить HTTP-запрос соответствующего доменного имени на HTTPS.
server {
listen 80;
server_name www.sherlocked93.club;
# 单域名重定向
if ($host = 'www.sherlocked93.club'){
return 301 https://www.sherlocked93.club$request_uri;
}
# 全局非 https 协议时重定向
if ($scheme != 'https') {
return 301 https://$server_name$request_uri;
}
# 或者全部重定向
return 301 https://$server_name$request_uri;
# 以上配置选择自己需要的即可,不用全部加
}
15.7 Разделение пути общего доменного имени
Это очень практичный навык, иногда нам может понадобиться настроить некоторые доменные имена второго или третьего уровня, надеясь автоматически указывать на соответствующий каталог через Nginx, например:
-
test1.doc.sherlocked93.club
автоматическое наведение/usr/share/nginx/html/doc/test1
адрес сервера; -
test2.doc.sherlocked93.club
автоматическое наведение/usr/share/nginx/html/doc/test2
адрес сервера;
server {
listen 80;
server_name ~^([\w-]+)\.doc\.sherlocked93\.club$;
root /usr/share/nginx/html/doc/$1;
}
15.8 Переадресация домена PAN
Как и в предыдущей функции, иногда мы хотим переписать ссылку доменного имени второго или третьего уровня на нужный нам путь, чтобы серверная часть могла разрешать разные правила в соответствии с маршрутом:
-
test1.serv.sherlocked93.club/api?name=a
Автоматически пересылать127.0.0.1:8080/test1/api?name=a
; -
test2.serv.sherlocked93.club/api?name=a
Автоматически пересылать127.0.0.1:8080/test2/api?name=a
;
server {
listen 80;
server_name ~^([\w-]+)\.serv\.sherlocked93\.club$;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://127.0.0.1:8080/$1$request_uri;
}
}
16. Лучшие практики
- Чтобы упростить обслуживание конфигурации Nginx, рекомендуется создать отдельный файл конфигурации для каждой службы, хранящийся в
/etc/nginx/conf.d
каталоге, вы можете создать столько независимых файлов конфигурации, сколько захотите. - Автономные файлы конфигурации, рекомендуется следовать приведенным ниже соглашениям об именах.
<服务>.conf
, например, доменное имяsherlocked93.club
, то ваш файл конфигурации должен выглядеть так/etc/nginx/conf.d/sherlocked93.club.conf
, если вы развертываете несколько сервисов, вы также можете добавить номер порта, перенаправленный Nginx, к имени файла, напримерsherlocked93.club.8080.conf
, если это доменное имя второго уровня, рекомендуется также добавитьfe.sherlocked93.club.conf
. - Обычно используемые конфигурации с высокой частотой мультиплексирования могут быть размещены в
/etc/nginx/snippets
Папка включена в место, которое необходимо использовать в файле конфигурации Nginx, названное в честь функции, а основная функция и местоположение введения отмечены в начале каждого файла конфигурации фрагмента для удобства управления. такой как предыдущийgzip
,cors
Для общих конфигураций я установил фрагменты. - Каталог, связанный с журналом Nginx, который начинается с
域名.type.log
по имени (напр.be.sherlocked93.club.access.log
а такжеbe.sherlocked93.club.error.log
)роды/var/log/nginx/
В каталоге настройте разные права доступа и файлы журналов ошибок для каждой независимой службы, чтобы было удобнее и быстрее находить ошибки.
Спасибо за напоминание от @木法传, когда Nginx настраивает защиту от пиявок, вы можете установить Baidu и Google в качестве белого списка, что хорошо для SEO.
Большинство сообщений в Интернете имеют разную глубину и даже некоторые несоответствия. Следующие статьи являются кратким изложением процесса обучения. Если вы найдете какие-либо ошибки, пожалуйста, оставьте сообщение, чтобы указать ~
Справочная документация:
- Документация Nginx на китайском языке
- Установка Nginx, подробная структура каталогов и файлы конфигурации
- Установка и настройка Keepalived
- Keepalived+Nginx обеспечивает высокую доступность
- Nginx и фронтенд разработка
- Подробное объяснение CORS для междоменного обмена ресурсами - веб-журнал Руан Ифэн
- Необходимые знания nginx для фронтенд-разработчиков
- Я также сказал, что Nginx решает междоменную проблему внешнего интерфейса, правильная междоменная конфигурация Nginx
- vue-router history mode nginx настроить и настроить кеш статических ресурсов | HolidayPenguin
- перенаправление nginx, глобальный https, конфигурация SSL, справочник по конфигурации обратной генерации
- Начало работы с Nginx
PS: адрес моего блогаGithub - SHERlocked93/blog, вы также можете обратить внимание на мой публичный аккаунт [послеобеденный чай], давайте работать вместе~
Кроме того, вы можете присоединиться к группе WeChat «Front-end Afternoon Tea Exchange Group», нажмите и удерживайте, чтобы определить QR-код ниже, чтобы добавить меня в друзья, обратите вниманиеДобавить группу, я заберу тебя в группу~