Конфигурирайте обратен прокси с Nginx стъпка по стъпка

  • Използване на Nginx като обратен прокси за подобряване на сигурността, производителността и мащабируемостта.
  • Практична конфигурация с множество сървъри, балансиране на натоварването и персонализирани заглавки.
  • Интеграция с WordPress и други стекове чрез поддиректории и upstream-ове.
  • Разширени опции: кеширане, SSL, контрол на времето за изчакване и изчистена структура на конфигурацията.
Daniel Terrasa

12 Minutos

конфигуриране на обратен прокси сървър с nginx

Конфигурирайте обратен прокси сървър с Nginx Това се превърна почти в де факто стандарт, когато искаме да подобрим производителността, сигурността и гъвкавостта на нашите уеб приложения. Независимо дали настройвате прост личен проект, сървър за упражнения или инфраструктурата на компания, рано или късно ще се наложи да поставите обратен прокси пред сървърите на приложенията си.

В тази статия ще видим какво точно представлява обратният прокси, как се различава от пренасочващия прокси, какви предимства предлага, как се вписва в WordPress и други стекове (Apache, Gunicorn, Kubernetes и др.) и най-вече как перфектно да конфигурираме Nginx като обратен прокси, включително балансиране на натоварването, персонализирани заглавки, кеширане, SSL и практически лабораторни примери с две Debian машини.

Какво е прокси и каква е разликата му от обратния прокси?

Преди да се докоснете до един конфигурационен файл, препоръчително е да имате ясно разбиране на включените в него концепции. Каква роля играе прокси сървърът в съвременната мрежова архитектура?Защото в противен случай е много лесно да се объркате с термини като директен прокси, обратен прокси, CDN, балансьор на натоварването, API шлюз и т.н.

  • „Нормален“ прокси (forward proxy) Прокси сървърът се поставя пред група клиенти (например компютри в офис, класна стая или домашна мрежа) и действа като посредник, когато тези компютри имат достъп до интернет. При типична комуникация без прокси, компютър А (клиентът) се свързва директно със сървър C (изходният сървър). С пренасочващ прокси, компютър А комуникира със сървър B (проксито), а сървър B след това комуникира със сървър C, получава отговора и го изпраща обратно на сървър A.
  • Обратният прокси представя обратния сценарийВместо да защитава анонимността на клиента, той защитава и абстрахира един или повече оригинални сървъри. Поставяме го „пред“ уеб сървъра или пула от сървъри, които хостват приложението (Apache, Nginx като уеб сървър, LiteSpeed, Gunicorn, Node.js, PHP-FPM и др.) и целият входящ потребителски трафик първо достига до този обратен прокси.

Ако дадем имена на машините разликата е яснаD биха били компютрите на потребителите, E - обратният прокси, а F - един или повече оригинални сървъри. Без обратен прокси, D би комуникирал директно с F. С обратен прокси, D вижда само E, а E решава как и към кой F да изпрати всяка заявка и как да върне отговора на D. Целта е да се предотврати директното свързване на клиенти с оригиналните сървъри.

Nginx

Защо си струва да използвате обратен прокси с Nginx

Използването на Nginx като обратен прокси не е прищявка. Става въпрос за ключов елемент да мащабираме сайт, да подобрим сигурността му и да опростим архитектурата, особено когато комбинираме различни технологии или искаме един домейн за множество услуги.

Едно от най-мощните предимства е балансиране на натоварването. Ако имате уебсайт с висок трафик, един backend сървър може да не е достатъчен. С обратен прокси можете да разпределяте заявки между множество origin сървъри, които обслужват едно и също съдържание. Ако един от тях се повреди или се претовари, останалите продължават да обслужват сайта, намалявайки единичните точки на отказ.

Обратният прокси също е високоефективен защитен щит Защото крие истинския IP адрес и други подробности за бекенд сървърите. Потребителите (и нападателите) виждат само проксито. Това прави много по-трудно стартирането на целенасочени атаки. Освен това, можете да защитите проксито с правила на защитната стена, основно HTTP удостоверяване, разширено филтриране на трафика или интеграция с WAF.

Друг ключов аспект е кеширане и уеб ускорение. Nginx, Varnish и други решения за обратна прокси могат да кешират статично и известно динамично съдържание, спестявайки ресурси на оригиналните сървъри и обслужвайки отговори от самия прокси, често от място по-близо до потребителя. Това намалява латентността и драстично подобрява времето за зареждане.

Накрая, обратният прокси опростява SSL/TLS криптирането и прекратяването. Оригиналният сървър не е необходимо да обработва криптирането и декриптирането на всички HTTPS връзки, тъй като обратният прокси може да действа като SSL терминатор, разтоварвайки натоварването на процесора и централизирайки управлението на сертификатите, дори разчитайки на специализиран хардуер за SSL ускорение, ако е необходимо.

NGINX като обратен прокси: характеристики и роля в съвременните архитектури

Nginx е един от най-широко използваните уеб сървъри и обратни проксита в света.Както във версията си с отворен код, така и в NGINX Plus (комерсиалното издание с разширени функции за мониторинг, управление на API и корпоративна поддръжка), той се използва като статичен уеб сървър, обратен прокси, балансьор на натоварването, SSL терминатор, Kubernetes ingress контролер и API шлюз.

Като обратен прокси, Nginx Намира се между клиентите и бекенд сървърите. (Apache, LiteSpeed, Gunicorn, PHP-FPM, Node.js и др.) и анализира всяка входяща заявка, за да реши какво да прави с нея: да я обслужи директно от кеша, ако е статична, да я препрати към съответния backend, ако е динамична, или да върне обработена грешка, ако нещо се обърка.

За да разпределя трафика между множество back-end сървъри, Nginx имплементира различни балансиращи алгоритми, като например кръгов метод (на редуване), „по-малко връзки“ (изпраща всяка нова заявка до сървъра с най-малко активни връзки) или IP хеширане (което помага сесията на клиента винаги да е свързана с един и същ бекенд).

NGINX Plus и други производни решения Тези възможности са подобрени с наблюдение в реално време, табла за управление на състоянието, разширени проверки на състоянието и динамични API за конфигурация, което се вписва много добре в облачните архитектури и внедряванията на Kubernetes, където Nginx обикновено действа като Ingress контролер.

nginx обратен прокси

Лабораторна настройка: два Debian сървъра с Nginx и обратен прокси

Много поучително упражнение за разбиране на Nginx като обратен прокси се състои от работа с две Debian машиниЕдиният действа като „краен“ уеб сървър (backend), а другият като обратен прокси. Винаги ще имате достъп до проксито от браузъра на вашата физическа машина, което ще пренасочва заявките към оригиналния уеб сървър.

Идеята е следната: на първата машина имате уебсайта си за упражнения (например от предишно упражнение с Nginx). Ще преименувате конфигурацията му, така че сайтът да се казва webserverПроменете порта за слушане на 8080 и се уверете, че той продължава да обслужва страницата правилно.

По-конкретно, в оригинален уеб сървър Вие трябва:

  • Преименувайте конфигурационния файл в /etc/nginx/sites-available и всяка вътрешна препратка към името на сайта, така че то да стане webserver.
  • Премахнете старата символична връзка в sites-enabled използване на unlink и създайте нова символна връзка, която сочи към преименувания файл.
  • Променете директивата listen 80; a listen 8080; в блока server съответстващ на този уебсайт.
  • Рестартирайте Nginx така че да приеме промените и да провери дали имате достъп до сайта http://webserver:8080 или чрез IP:8080.

На втората Debian машина ще конфигуриране на Nginx като обратен прокси сървърОсновни стъпки:

  • Създайте конфигурационен файл в /etc/nginx/sites-available с името на вашия тестов домейн, например ejemplo-proxy.
  • Дефиниране на блок server лесно с порта, на който проксито ще слуша (80 или друг, ако искате допълнително да разграничите ролите) и server_name с домейна или псевдонима на вашия прокси сървър.
  • Вътре в блока location /, настройвам proxy_pass сочейки към IP адреса и порта на бекенда, например proxy_pass http://192.168.1.50:8080; o http://webserver:8080; ако имате вътрешен DNS.
  • Създайте символната връзка в sites-enabled и тествайте конфигурацията с nginx -t.

Ако всичко върви добре, след презареждане на Nginx Ще можете да достъпвате сайта си, използвайки името на прокси сървъра, и ще виждате съдържанието, което действително се предоставя от backend уеб сървъра, но през цялото време преминава през обратния прокси сървър.

Добавете персонализирани заглавки, за да демонстрирате пътя на заявката

Много ясен начин да се провери дали заявката преминава през проксито и достига до оригиналния сървър е Добавете персонализирани HTTP заглавки от двете страни и след това да ги видите от инструментите за разработчици на браузъра.

Практиката се състои от Конфигурирайте както обратния прокси, така и уеб сървъра така че да включат допълнителен заглавен файл в отговорите, например използвайки директивата add_header вътре в блока location / { ... }Заглавката може да бъде нещо подобно X-Host: Proxy_inverso_tunombre в пълномощника и X-Host: Servidor_web_tunombre на задния край.

El препоръчителен поток обикновено:

  1. Добавете първо заглавката, само в обратния прокси сървърРестартирайте Nginx и проверете дали все още имате нормален достъп до сайта.
  2. Отворете инструментите за разработчици на браузъра (F12) и проверете раздела „Мрежа“Избиране на основната заявка и преглед на заглавките на отговора, за да се види новата заглавка, добавена от проксито.
  3. Сега добавете заглавката към конфигурацията на оригиналния уеб сървър, с различна стойност, за да го разграничите, и отново рестартирайте Nginx на този сървър.
  4. Обновете страницата, като деактивирате кеша на браузъра или в частен прозорец, за да се гарантира, че отговорите действително идват от сървъра.

Ако всичко е настроено правилно, В HTTP отговорите ще видите двата заглавки, единият генериран от обратния прокси сървър, а другият от уеб сървъра, потвърждаващи, че заявката е изминала пълния път за двупосочно пътуване през прокси сървъра.

Nginx

„Класическа“ Nginx конфигурация като прост обратен прокси сървър

Минималната конфигурация на Nginx, необходима за работа като обратен прокси сървър, е много проста.Но от тази основа могат да се добавят много подобрения. Представете си, че искате заявките да /example напред към https://example.comПростото добавяне на блок би било достатъчно. location до блока server подходящо:

location /example {
proxy_pass https://example.com;
}

Този фрагмент показва, че всяка заявка, чийто път започва с /example Ще бъде изпратено до посочената дестинация в proxy_passЧесто е придружено от други директиви за коригиране на заглавките, времето за изчакване и поведението при пренасочване.

По-пълна версия за поддиректория от тип блог би могла да има по този начин:

server {
listen 80;
server_name example.com;

населено място / {
try_files $uri $uri/ /index.php?$query_string;
}

местоположение /блог {
proxy_pass http://blog.domain.com;
proxy_http_версия 1.1;
proxy_cache_bypass $http_upgrade;

proxy_set_header Надграждане $http_upgrade;
proxy_set_header Връзка «надграждане»;
proxy_set_header Гост $ хост;
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header X-предаден-За $ proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $ схема;
proxy_set_header X-Пренасочен хост $host;
proxy_set_header X-Пренасочен порт $server_port;

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}

Ключът тук е proxy_pass сочейки към задния край и набор от заглавки, които гарантират, че оригиналният сървър знае истинския IP адрес на клиента, оригиналната схема (HTTP или HTTPS) и други важни данни за лог файлове и за приложения, които зависят от тези заглавки.

Най-добри практики за структура и конфигуриране на файлове на Nginx

Когато инсталирате Nginx на дистрибуция като Ubuntu или DebianТипичната структура на конфигурацията е организирана в няколко директории, които трябва да се спазват, за да се избегне създаването на хаос с нарастването на броя на сайтовете.

Ключовите моменти на тази структура са:

  • /etc/nginx/nginx.conf, основният конфигурационен файл, където са дефинирани глобалните директиви и са включени други файлове.
  • /etc/nginx/sites-available/, който съхранява конфигурационните файлове за всеки виртуален сайт, активен или не.
  • /etc/nginx/sites-enabled/, който съдържа символни връзки към сайтове, които действително са активни.
  • /etc/nginx/conf.d/където можете да поставите допълнителни глобални конфигурации във файлове .conf които се таксуват автоматично.

Работи с sites-available y sites-enabled има няколко предимство. Можете да подготвите конфигурацията на сайт, без да го активирате, докато не създадете символната връзка, да деактивирате сайтовете, като премахнете само символната връзка, и да запазите конфигурацията на всяка услуга групирана в един, лесен за намиране файл.

Във всеки файл на сайта обикновено ще намерите няколко блока serverвсеки със свои собствени директиви listen, server_name и различни блокове locationПоследните определят как се обработват различните маршрути (статични, прокси, API и др.), например чрез обслужване /static/ директно от диска и изпращане /api/ към Node.js backend.

Общата препоръка е Винаги тествайте настройките преди презареждане използване на sudo nginx -tза да избегнете спиране на услугата поради проста синтактична грешка и използвайте systemctl reload nginx винаги когато е възможно, тъй като това презарежда конфигурацията, без да прекъсва активните връзки.

Инсталация и първи стъпки с Nginx като обратен прокси сървър в Ubuntu/Debian

Ако настройвате VPS от нулата или машина за тренировки, стъпките за работа на Nginx като обратен прокси на Ubuntu 22.04 (или подобен) са доста прости и могат лесно да бъдат автоматизирани със скриптове.

Типична последователност на инсталиране:

  • Актуализирайте пакетите с sudo apt update y sudo apt upgrade -y за да се уверите, че всичко е актуално.
  • Инсталиране на Nginx с sudo apt install nginx -y, което ще стартира услугата автоматично.
  • Проверете състоянието на услугата използване на sudo systemctl status nginx да видя какво изглежда като активен (работи).
  • Отворете защитната стена В случай на използване на UFW, с sudo ufw allow 'Nginx Full' да се разреши трафикът в портове 80 и 443.

След като Nginx е инсталиран, можете Създайте първия си виртуален хост en /etc/nginx/sites-available/ejemplo.com и го свържете sites-enabledОттам просто трябва да добавите блок location / да направя proxy_pass към бекенда и препоръчителните заглавки, така че приложението от другата страна да получи цялата необходима информация.

В по-напреднали среди е често срещано сдвоете Nginx с други части като Certbot за получаване на сертификати Let's Encrypt, Gunicorn за Python приложения или дори настройване на обратен прокси на Raspberry Pi, който пренасочва трафика към вътрешни услуги (NAS, административни панели и др.) с пренасочване на портове от рутера към машината с Nginx.

Разширени опции: балансиране на натоварването, кеширане, SSL и фина настройка на прокси политиките

След като усвоите основната настройка на обратния прокси, е много изкушаващо да спрете дотук. Но Nginx предлага много директиви, които ви позволяват да за да се увеличи максимално производителността и контролът.

за създаване на балансьор на натоварването първо дефинирате блок upstream с бекенд сървърите и след това използвате proxy_pass сочейки към това нагоре по течението:

upstream myapp1 {
server backend1.example.com;
server backend2.example.com;
}

сървър {
слушате 80;
име на сървъра example.com;

населено място / {
proxy_pass http://myapp1;
грешка proxy_next_upstream време на изчакване;
}
}

за Сервирайте статично съдържание директно от прокси сървъраМожете да дефинирате допълнителен блок за местоположение:

server {
listen 80;
server_name example.com;

населено място / {
прокси_пас http://backend.example.com;
}

местоположение /статично/ {
root /път/до/статични/файлове;
изтича 30d;
}
}

Относно директиви proxy_*Някои от най-често използваните са:

  • proxy_set_header за да коригирате заглавки като Host, X-Real-IP o X-Forwarded-ProtoОснови на съвременните уеб приложения.
  • proxy_cache y proxy_cache_pathЗа активиране и конфигуриране на кешове за обратен прокси, които намаляват натоварването на backend-а.
  • proxy_buffering да реши дали Nginx буферира отговорите или ги предава поточно, което може да намали латентността в определени API.
  • proxy_connect_timeout, proxy_read_timeout y proxy_send_timeoutЗа да се контролира кога даден бекенд се счита за неотговарящ и да се премине към следващия или да се върне грешка.
  • proxy_ssl и свързани параметри ако трафикът между Nginx и backend-а е криптиран с HTTPS.

Когато съберете всички тези части заедно – обратен прокси, балансиране на натоварването, кеширане, SSL и мониторинг –Nginx се превръща в централния хъб, през който преминава абсолютно целият трафик на вашите приложения. Познаването на правилното му конфигуриране и разбирането на ролята му в архитектурата правят цялата разлика между крехка система и такава, способна да се мащабира, да устои на атаки и да осигурява много ниско време за реакция дори при голямо натоварване.