Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр
Это idle-игра стратегия о рыцарях, исследованиях, крафте и сражениях, которая предоставляет пользователям расслабляющий опыт. Игра не требует концентрации и идеально подходит, когда вам нужно сделать перерыв или отдохнуть.

Герои Мини-Королевства

Кликер, Стратегии, Мидкорные

Играть

Топ прошлой недели

  • CharlotteLink CharlotteLink 1 пост
  • Syslikagronom Syslikagronom 7 постов
  • BydniKydrashki BydniKydrashki 7 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Новости Пикабу Помощь Кодекс Пикабу Реклама О компании
Команда Пикабу Награды Контакты О проекте Зал славы
Промокоды Скидки Работа Курсы Блоги
Купоны Biggeek Купоны AliExpress Купоны М.Видео Купоны YandexTravel Купоны Lamoda
Мобильное приложение

Nginx

С этим тегом используют

Рамблер Linux IT Все
70 постов сначала свежее
1
user10701700
user10701700
24 дня назад

Как мы боролись с DDoS-атакой (и победили)⁠⁠

✨ Предисловие

Для модераторов. В статье нет рекламы.
Кажется, у нас появился настоящий "фанат", причём настолько страстный, что решил обрушить наш сайт массированной DDoS-атакой. Сначала мы даже улыбнулись — ну, внимание приятно. Но серверу было не до шуток.

Несмотря на то, что у нас стоял сервис от DDOS (не буду писать, а то подумают реклама), включение режима JS Challenge не помогло — часть запросов всё равно проходила, и сервер ложился от нагрузки. Пришлось действовать решительно.


🧱 Первый рубеж обороны: чёрный список IP

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


🧠 Вдохновение: а давайте подключим Fail2ban?

Так и родилась идея: использовать fail2ban для автоматической защиты на уровне сервера. И, скажем прямо, это было отличное решение.


🔧 Установка Fail2ban

Устанавливаем через APT:

sudo apt install fail2ban


🎯 Фокус на точку атаки

Нам повезло: злоумышленник атаковал один конкретный адрес —
https://site/login/
https://site/register/
https://site/wp-login.php
и прочие варианты по шаблону

Это дало преимущество: множество повторяющихся POST-запросов с одного IP — именно то, что умеет отсекать fail2ban.


🛠 Создание фильтра

Создаём фильтр:
/etc/fail2ban/filter.d/wordpress.conf

[Definition]
failregex = ^ - - [.] "POST /login/ HTTP/." (200|403|404)

📌 Что делает фильтр?
Он отслеживает POST-запросы к /login/, которые получают коды ответа:

  • 200 — успешный доступ (например, фальшивая регистрация)

  • 403 — доступ запрещён

  • 404 — страницы не существует (спамеры промахнулись)


⚙️ Настройка Jail

Открываем файл:
/etc/fail2ban/jail.local
и добавляем:

[wordpress-register]
enabled = true
filter = wordpress
logpath = /var/log/nginx/domains/site.log
maxretry = 5
findtime = 60
bantime = 36000000
action = iptables[name=wordpress-register, port="http,https", protocol=tcp]

📌 Объяснение параметров:

  • enabled = true — включаем правило

  • filter = wordpress — имя фильтра без .conf

  • logpath — путь к nginx-логу

  • maxretry = 5 — допустимое количество попыток до бана

  • findtime = 60 — за какой период искать попытки (в секундах)

  • bantime = 36000000 — сколько длится бан. Это ~68 лет 😄

  • action — блокировка через iptables на порт 80 и 443 (HTTPS)


✅ Проверка фильтра

Перед применением можно протестировать фильтр:

fail2ban-regex /var/log/nginx/domains/site.log /etc/fail2ban/filter.d/wordpress.conf


🚀 Запускаем защиту

Применяем конфигурацию:

sudo fail2ban-client reload
sudo systemctl restart fail2ban (Перезапускать службу не всегда желательно, так как он забывает все заблокированные IP адреса, а это плохо при массированной атаке, поэтому рекомендую использовать только fail2ban-client reload, где обновляются правила)


📊 Проверяем результат

Проверка статуса:

fail2ban-client status wordpress-register

Пример:

Status for the jail: wordpress-register
|- Filter
| |- Currently failed: 138
| |- Total failed: 6038
| - File list: /var/log/nginx/domains/site.log - Actions
|- Currently banned: 821
|- Total banned: 821
`- Banned IP list: 1.20.227.66 101.126.80.238 ...

Если видите IP — значит, fail2ban работает.

Дополнительно можете проверить цепочку в iptables:

sudo iptables -L f2b-wordpress-register -n


После этого наш фанат решил проявить смекалку и нам пришлось создать еще несколько правил.

Открываем файл:
/etc/fail2ban/jail.local
и добавляем:

[wordpress-ddos]
enabled = true
filter = wordpress-ddos
logpath = /var/log/nginx/domains/site.log
maxretry = 5
findtime = 60
bantime = 36000
backend = auto
action = iptables[name=wordpress-ddos, port="http,https", protocol=tcp]

[hestia-ddos]
enabled = true
filter = hestia-ddos
logpath = /var/log/hestia/nginx-access.log
maxretry = 90
findtime = 60
bantime = 360
action = iptables[name=hestia-ddos, port=8027, protocol=tcp]

[site-ddos-param]
enabled = true
filter = site-ddos-param
logpath = /var/log/nginx/domains/site.log
findtime = 60
maxretry = 2
bantime = 360000
action = iptables[name=site-ddos-param, port="http,https", protocol=tcp]

[nginx-ddos-errorlog]
enabled = true
filter = nginx-ddos-errorlog
logpath = /var/log/nginx/domains/site.error.log
findtime = 60
maxretry = 3
bantime = 86400
action = iptables[name=nginx-ddos-errorlog, port="http,https", protocol=tcp]

[nginx-referrer-selfip]
enabled = true
filter = nginx-referrer-selfip
logpath = /var/log/nginx/domains/site.log
findtime = 60
maxretry = 1
bantime = 2592000 # 30 дней
action = iptables[name=referrer-selfip, port="http,https", protocol=tcp]

Все правила писали через регулярные выражения

/etc/fail2ban/filter.d/hestia-ddos.conf
[Definition]
failregex = ^ - - [.] "." [2-5][0-9]{2} .*

/etc/fail2ban/filter.d/site-ddos-param.conf
[Definition]
failregex = ^ - - [.] "GET /?\d{5,} HTTP/." [2-5][0-9]{2} .*

/etc/fail2ban/filter.d/nginx-ddos-errorlog.conf
[Definition]
failregex = ^\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2} [error].access forbidden by rule, client: , server: ., request: "GET /?\d{6,} HTTP/1.1"

/etc/fail2ban/filter.d/nginx-referrer-selfip.conf
[Definition]
failregex = ^ - - [.] "GET ." \d+ \d+ "https?://.100.90.80.70."


🚀 Договариваемся с nginx

Так же часть запросов ?78698675876 грузили сервер, т.е. Fail2ban пропускал запросы к серверу из-за того, что трафика было много, но мы это решили делать пересылку на 403 запрос, что бы экономить ресурсы сервера

Открываем файл:
/etc/nginx/conf.d/domains/site.ssl.conf
и добавляем:

Между блоком

server {

...

#Slait
# Блокировать запросы с реферером, содержащим наш IP
if ($http_referer ~* "100\.90\.80\.70") {
return 403;
}

# Блокировать GET-запросы типа /?123456 (только цифры в query string)
if ($request_uri ~* "^/\?\d{9,}$") {
return 403;
}
#Slait

...
}

Применяем конфигурацию:
sudo systemctl restart nginx

🎉 Итог

Fail2ban помог нам перехватить атаку в реальном времени, за считанные минуты блокируя сотни IP-адресов. Простая настройка и мощный результат — рекомендуем!

Показать полностью
Nginx Информационная безопасность DDoS Длиннопост
10
20
0sennijLis
0sennijLis
1 месяц назад
Лига Сисадминов

Продвинутая защита Nginx⁠⁠

Nginx — пока еще один из самых популярных веб-серверов, и ключевой компонент современной корпоративной архитектуры. В этой статье мы рассмотрим базовые параметры конфигурации (доступные "из коробки"), которые упрощают мониторинг, улучшают производительность и усиливают безопасность — в конечном итоге повышая устойчивость вашей инфраструктуры.

Логирование в формате JSON

JSON — лучший выбор формата для логов Nginx по двум основным причинам. Во-первых, он гораздо более читаем для человека. Во-вторых, передача логов в такие системы, как OpenSearch, для последующего мониторинга или в рамках SIEM-решений становится сильно проще.

Вот простой пример из nginx.conf:

log_format json-logger escape=json '{

"type": "access-log",

"time": "$time_iso8601",

"remote-ip": "$remote_addr",

"x-forward-for": "$proxy_add_x_forwarded_for",

"request-id": "$request_id",

"request-length": "$request_length",

"response-bytes": "$bytes_sent",

"response-body-size": "$body_bytes_sent",

"status": "$status",

"vhost": "$host",

"protocol": "$server_protocol",

"path": "$uri",

"query": "$args",

"duration": "$request_time",

"backend-duration": "$upstream_response_time",

"backend-status": "$upstream_status",

"method": "$request_method",

"referer": "$http_referer",

"user-agent": "$http_user_agent",

"active-connections": "$connections_active"

}';

access_log /var/log/nginx/access.log json-logger;

Это приведёт к следующему выводу в файле access.log:

{

"type": "access-log",

"time": "2025-02-25T16:02:54+00:00",

"remote-ip": "130.61.78.239",

"x-forward-for": "130.61.78.239",

"request-id": "38750f2a1a51b196fa0a76025b0d1be9",

"request-length": "258",

"response-bytes": "353",

"response-body-size": "167",

"status": "404",

"vhost": "3.69.78.187",

"protocol": "HTTP/1.1",

"path": "/lib/phpunit/Util/PHP/eval-stdin.php",

"query": "",

"duration": "0.016",

"backend-duration": "0.016",

"backend-status": "404",

"method": "GET",

"referer": "",

"user-agent": "Custom-AsyncHttpClient",

"active-connections": "1"

}

Параметризация запросов

Большие размеры тела запроса, длительные тайм-ауты и чрезмерно увеличенные настройки KeepAlive могут негативно повлиять на производительность. Чтобы повысить эффективность, лучше устанавливать эти параметры на минимально возможные значения — при этом, само собой, соблюдая требования вашего приложения.

Пример из nginx.conf:

client_max_body_size 10M;

client_body_timeout 10s;

client_header_timeout 10s;

keepalive_timeout 5s 5s;

Описание параметров:

  • client_max_body_size

Определяет максимальный размер тела HTTP-запроса, который клиент может отправить. Если лимит превышен, Nginx возвращает ошибку 413 Request Entity Too Large.

  • client_body_timeout

Задает максимальное время ожидания полного тела запроса. Если за это время тело не получено, соединение будет закрыто.

  • client_header_timeout

Устанавливает максимальное время ожидания полного заголовка HTTP-запроса от клиента. Если лимит превышен — соединение также закрывается.

  • keepalive_timeout

Определяет, как долго будет оставаться открытым соединение Keep-Alive после последнего запроса.

Первый параметр (например, 5s) задаёт тайм-аут на стороне сервера. Второй (опциональный) параметр передаётся клиенту как предложение о том, как долго он может держать соединение открытым.

Ограничение количества запросов

На случай если клиент пытается перегрузить веб-сервер частыми запросами, Nginx предоставляет возможность настроить "зоны ограничения запросов" (limit request zones) — для контроля трафика по различным параметрам.

Пример настройки (реверс-прокси с зоной ограничения запросов):

limit_req_zone $binary_remote_addr zone=limitreqsbyaddr:20m rate=15r/s;

limit_req_status 429;

upstream app.localhost {

server localhost:8080;

}

server {

listen 443 ssl;

server_name app.devlab.intern;

location / {

limit_req zone=limitreqsbyaddr burst=10;

proxy_pass http://app.localhost;

}

}

Пояснение параметров:

  • $binary_remote_addr

Используется для настройки зоны ограничения по IP-адресу клиента. Адрес сохраняется в бинарной форме (это снижает потребление памяти).

  • zone=limitreqsbyaddr:20m

Создаёт общую (shared) область памяти объёмом 20 МБ с именем limitreqsbyaddr. В этой зоне хранятся данные о лимитах для разных IP-адресов.

  • rate=15r/s

Ограничивает количество запросов до 15 запросов в секунду на IP. Превышение лимита приводит к отклонению избыточных запросов.

  • limit_req_status 429;

При превышении лимита Nginx возвращает статус 429 Too Many Requests, что означает: "Слишком много запросов за короткое время".

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

Ограничение только на необходимые HTTP-методы

На мой взгляд, ограничение допустимых HTTP-методов только теми, которые действительно необходимы или поддерживаются приложением (например, REST API), — это чистый и логичный способ синхронизации настроек веб-сервера с логикой приложения. Это помогает не только предотвратить неправильное использование API или вызов нежелательных методов, но и блокирует потенциально опасные запросы вроде TRACE. Кроме того, это снижает ненужную нагрузку на сервер, устраняя неподдерживаемые или неуместные запросы.

Пример: разрешён только метод GET (HEAD разрешается по умолчанию):

# HEAD is implicit

limit_except GET {

deny all;

}

Пример: разрешить все методы, кроме TRACE и PATCH:

if ($request_method ~ ^(PATCH|TRACE)$) {

return 405;

}

Простая защита от ботов

Если на сервер поступают запросы от ботов или плохо сконфигурированных сканеров (часто с «говорящими» user-agent'ами), можно внести путаницу и затруднить их работу, возвращая нестандартный статус HTTP от самого Nginx.

Для этого создаём файл bot.protection.conf в директории /etc/nginx/snippets со следующим содержимым:

map $http_user_agent $blacklist_user_agents {

~*wpscan 1;

~*dirbuster 1;

~*gobuster 1;

}

Вы можете дополнять список по мере необходимости.

Внутри конфигурации виртуального хоста (VHost) подключите файл следующим образом:

include /etc/nginx/snippets/bot.protection.conf;

if ($blacklist_user_agents) {

return 444;

}

HTTP 444 также можно «весело» использовать для предотвращения угадывания служебных файлов, таких как .env:

# <your-domain>/.bash_history for example ends with HTTP 444.

location ~ /\. {

return 444;

}

Что означает HTTP 444?

HTTP 444 — это нестандартизированный статус-код, используемый в NGINX, который заставляет сервер мгновенно закрыть соединение без отправки заголовков ответа клиенту. Чаще всего используется для отклонения вредоносных или некорректно оформленных запросов. Интересный побочный эффект: некоторые сканеры не умеют корректно обрабатывать такие ответы, что добавляет дополнительный уровень защиты.

Включение TCP Fast Open

TCP Fast Open — это важное улучшение в Nginx, которое позволяет более эффективно устанавливать TCP-соединения. Эта функция даёт возможность начать передачу данных уже во время начального рукопожатия, что заметно ускоряет процесс установления соединения. Особенно полезна она в условиях высокой сетевой задержки, так как помогает сократить латентность и повысить производительность.

Проверка поддержки TCP Fast Open в ядре Linux

Выполните следующую команду:

cat /proc/sys/net/ipv4/tcp_fastopen

Если в ответе вернётся 1, функция уже включена. Если нет — включите её командой:

echo 1 > /proc/sys/net/ipv4/tcp_fastopen

Использование в конфигурации Nginx

Добавьте параметр fastopen в директивы listen:

listen [::]:443 ssl http2 fastopen=500;

listen 443 ssl http2 fastopen=500;

Число 500 — это количество подключений, которые могут использовать TCP Fast Open одновременно (значение можно адаптировать под вашу нагрузку).

Сжатие с помощью GZip

GZip — это метод сжатия данных, позволяющий уменьшить размер файлов. При этом исходные данные можно полностью восстановить путём распаковки («разархивирования») сжатого файла.

Для веб-приложений и сайтов GZip особенно важен, поскольку HTTP-протокол поддерживает передачу данных в сжатом виде до того, как они попадут в сеть.

Почему GZip важен:

  • Снижение трафика: при включённом GZip размер передаваемых файлов уменьшается, что приводит к меньшему потреблению пропускной способности.

  • Экономия на хостинге: меньше трафика — ниже затраты на обслуживание.

  • Ускорение загрузки для пользователей: посетители получают более лёгкие файлы, что сокращает время загрузки страниц.

Пример конфигурации:

gzip on;

gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Эта настройка включает GZip и указывает типы содержимого, которые следует сжимать (текст, CSS, JavaScript, XML, JSON и др.).

Показать полностью
IT Linux Гайд Системное администрирование Nginx Компьютерные сети Текст Длиннопост
9
ITFrogs
6 месяцев назад

У Паудер тормозит Apache⁠⁠

У Паудер тормозит Apache Arcane, Apache, Nginx, Картинка с текстом, Мемы, Юмор

Здесь игра слов Джинкс - Nginx

[моё] Arcane Apache Nginx Картинка с текстом Мемы Юмор
3
ignatWHM
7 месяцев назад
Web-технологии

Почему LiteSpeed - серверы выигрывают у Apache и Nginx?⁠⁠

В современном веб пространстве скорость и производительность сайтов имеют решающее значение. Пользователи ожидают быстрой загрузки страниц, а поисковые системы учитывают время отклика при ранжировании. Поэтому выбор веб-сервера имеет критически важное значение. Давайте разберемся почему LiteSpeed часто превосходит Apache и Nginx.

1. Высокая производительность и скорость.

Представьте себе веб-сервер, который способен жонглировать тысячями запросов, не проливая ни капли пота. Это LiteSpeed! Благодаря своей событейно-ориентированной архитектуре, он работает так же быстро, как кофе по утрам!)
В то время как Apache все еще пытается проснуться со своей процессной архитектурой, LiteSpeed уже пробежал марафон.

2. Встроенное кэширование с LSCache

Вот кто не любит, когда все работает быстрее? LSWS приходит с подарком - встроенным кэшэм. Это как личный шеф-повар, который зарнее готовит ваши любимые блюда)
Ваш сайт будет подавать страницы так быстро, что пользователи предположат, что вы предсказываете их желания))) И конечно он дружит с такими CMS как Wordpress, Joomla и прочие..

3. Поддержка современных протоколов

LiteSpeed - всегда вкурсе последних трендов.
Имеется поддежка HTTP/3 и QUIC, что делает передачу данных быстрее скорости света. Это особенно круто для мобильных пользователей и тех, кто сидит на интернете с улиточной скоростью - теперь все будет летать!)

4. Эффективное использование ресурсов

Цены на железо достигают колосальных цен, а зачем тратить больше, когда можно тратить меньше?
LiteSpeed экономит оперативную память и процессорное время так, словно сам за них платит)
Большее кол-во пользователей может быть обслуженно на том же железе, позволяя вам сэкономить на инфраструктуре, потратьте эти деньги на родных и близких ;)

5. Совместимость с Apache

Боитесь перермен? Я тоже. Как хорошо, что LiteSpeed полностью совместим с конфигурационными файлами Apache. Переходите на РЕАЛЬНО хороший вебсервер без головной и жопной боли из за переписывания всех настроек с нуля.

6. Бесплатная версия OpenLiteSpeed.

Не уверенны? Хотите попробовать, а трайл версии мало? OpenLiteSpeed идеальный вариант для временного решение, ведь по функционалу, он не сильно то и урезан, грубо говоря чуть более старая версия нынешнего LiteSpeed.

Заключение

К чему эта статья? Создатели веб-серверов, хватит уже жить в эпохе динозваров! Нам, пользователям, нужна скорость и удобство. Зачем нам Apache и Nginx, когда есть нечтно новее, с GUI и высокой производительностью?

Не время ли оставить старые добрые и "ламповые" сервера для музеев технологий? Зачем нам разгонять интернет на паровой машине, когда давно придумали реактивные двигатели.

И, честно говоря, кто станет использовать веб-сервера, требующие знания древних заклинаний для настройки? Может, некоторым хостингам кажется, что это весело? Ну что ж, пусть продолжают жить в мире дискет и модемов)) (Привет синийхост точка ком)

Давайте двигаться вперед и использовать современные технологии, которые делают жизнь проще, а сайты быстрее)
Мы все заслуживаем скорость света в интернете, а не прогулки с черепахой, мы же платим за это деньги!

Показать полностью
[моё] Сервер Apache Nginx Web Сайт Web-программирование Программирование Текст
9
0
MaxxDamage
MaxxDamage
11 месяцев назад
Лига Сисадминов

Глюки с Редмайном⁠⁠

Доброго времени суток. Столкнулся с трудноуловимым и малопонятным багом в Редмайне.
В общем, имеется сервер с Редмайном. Доступ есть и из локальной сети, и извне. Для доступа извне, на веб-сервере (другая машина) в nginx настроено проксирование.
Так вот, теперь, при доступе из локали, например по ip-адресу в адресной строке, всё работает нормально. Но если заходить извне, по доменному имени, то проявляется следующий баг:
Добавляем к задаче комментарий (допустим, "ТЕСТ"). Сохраняем его. Редактируем этот комментарий (ТЕСТ2). Сохраняем. И при повтором редактировании, комментарий отображается как самый первый (ТЕСТ). Пробовал искать информацию по такому глюку - не нашёл, потому что сложноописумый.
Подозреваю что дело в проксировании (так как в локали глюк не проявляется), но правило там стандартное:

server {

server_name redmine.example.com www.redmine.example.com;

location / {

proxy_pass http://192.168.1.253;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

client_max_body_size 0;

client_body_buffer_size 128k;

}

}

Доступ по протоколу HTTP, как изнутри, так и снаружи.

Может тут кто с таким сталкивался, или знает в какую сторону копать?

Показать полностью
Nginx Debian Linux Компьютерная помощь Текст
40
2
user9315307
user9315307
11 месяцев назад

Немного о пет-проектах⁠⁠

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

На самом деле желание сделать что-то свое возникает не только в IT, но эта область требует минимальных финансовых вложений, поэтому пробовать и ошибаться не так страшно и накладно. К сожалению, выбор приходит с опытом, поэтому юные джуны мучаются вопросом, что еще сделать, кроме «todo list». Но когда у тебя есть опыт и в «оффлайне», то найти, куда приложить новые IT-знания, становится значительно проще. Один из моих пет-проектов, воплотив который, за короткий срок я изучил и использовал много новых для себя технологий: Vue, Docker, Nginx, JWT-аутентификацию, ИИ-модели, Mongo, Git, Node.

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

Мой сети - https://t.me/apicraft https://www.youtube.com/@jspytop http://apicraft.ru/

UPD:

https://gitlab.com/slavafumin/smartnote

Показать полностью
[моё] Vue Docker Nginx Git Node IT Опыт Программирование Саморазвитие Видео YouTube
1
user8778065
1 год назад

Avanpost.IDM Linux⁠⁠

Кто-нибудь разбирается в системе avanpost.idm и как правильно настроить конфиги для веб-сервера nginx?

Linux Nginx Unix Idm Текст Нужен совет
4
125
0sennijLis
0sennijLis
1 год назад
Лига Сисадминов

Понимание основных принципов работы прямых и обратных прокси-серверов⁠⁠

Это скорее статья-заметка. Без особого погружения в дебри технологий, и нюансы работы. Исключительно поверхностное рассмотрение основных различий.

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

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

Если говорить более формальными терминами, то:

Прокси-сервера - это посредники между клиентами, запрашивающими ресурсы, и серверами, предоставляющими ресурсы.

Различие между разными типами прокси-серверов (такими например как прямой и обратный) зависит от вашего сценария использования, и ваших специфичных требований. Давайте рассмотрим эти типы подробно.

Прямой прокси (Forward Proxy)

Этот тип серверов действует как посредник между клиентом и интернетом. Когда клиент запрашивает ресурс, прямой прокси-сервер получает доступ к ресурсу от имени клиента, и пересылает его обратно клиенту.

Понимание основных принципов работы прямых и обратных прокси-серверов IT, Сервер, Прокси, Nginx, Сети, Длиннопост

Вы можете задаться справедливым вопросом. Почему бы просто напрямую не отправлять запросы на сервер, не используя посредника? Есть несколько причин, по которым такой вариант не видится предпочтительным:

  • лучше контроль за интернет трафиком: Прямой прокси может разрешать или запрещать доступ к определённым ресурсам, контенту или сервисам, основываясь на описанных правилах. Это ценно для организаций, которые отслеживают и регулируют деятельность сотрудников или студентов в Интернете, а также для родителей, ограничивающих пребывание своих детей в Интернете.

  • экономия пропускной способности, и повышение скорости: с помощью кэширования часто посещаемых ресурсов прокси сервер ускоряет время загрузки страниц, и сокращает сетевой трафик.

  • улучшение приватности и безопасности: прокси-сервер может скрыть пользовательский IP адрес и другую идентификационную информацию от конечного сервера, что в свою очередь создаёт сложности для отслеживания пользователя. Он так же может шифровать пользовательские запросы и ответы, предотвращая перехват или взлом. Это большое преимущество для пользователей, которые хотят обезопасить свои персональные данные.

  • Обход цензуры: прокси помогает пользователям получать доступ к контенту и сервисам, которые заблокированы или запрещены в их сети (провайдером или правительством). Это достигается путем маршрутизации запросов через другое местоположение или IP-адрес, на которые не распространяются те же ограничения. Это выгодно для пользователей, которые ищут больше онлайн-свободы.

Обратный прокси (Reverse Proxy)

Понимание основных принципов работы прямых и обратных прокси-серверов IT, Сервер, Прокси, Nginx, Сети, Длиннопост

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

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

Другая важная фича обратного прокси - SSL Termination. Когда клиент запрашивает безопасное соединение (HTTPS), обратный прокси-сервер может обрабатывать процессы шифрования и дешифрования, освобождая серверные серверы от этой ресурсоёмкой задачи. Это не только улучшает производительность приложений, но еще и упрощает управление сертификатами SSL.

Некоторые примеры обратных прокси:

  • Nginx: в особом представлении не нуждается. Это высокопроизводительный open-source веб-сервер, который так же может работать в качестве обратного прокси. Он поддерживает различные протоколы, алгоритмы балансировки нагрузки, механизмы кэширования и настройки безопасности.

  • Varnish: Open-source обратный прокси-сервер HTTP с встроенным механизмом кэширования, предназначенный для ускорения веб-приложений.

  • Apache Traffic Server: Обратный и кэширующий сервер с открытым исходным кодом, способный обрабатывать миллионы одновременных подключений и различных протоколов.

  • Istio: Istio - это сервисная сетка с открытым исходным кодом, которая улучшает взаимодействие микросервисов с помощью таких функций, как обнаружение сервисов, балансировка нагрузки, маршрутизация трафика и многое другое.

Заключение

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

Показать полностью 2
IT Сервер Прокси Nginx Сети Длиннопост
15
Посты не найдены
О Нас
О Пикабу
Контакты
Реклама
Сообщить об ошибке
Сообщить о нарушении законодательства
Отзывы и предложения
Новости Пикабу
RSS
Информация
Помощь
Кодекс Пикабу
Награды
Команда Пикабу
Бан-лист
Конфиденциальность
Правила соцсети
О рекомендациях
Наши проекты
Блоги
Работа
Промокоды
Игры
Скидки
Курсы
Зал славы
Mobile
Мобильное приложение
Партнёры
Промокоды Biggeek
Промокоды Маркет Деливери
Промокоды Яндекс Путешествия
Промокоды М.Видео
Промокоды в Ленте Онлайн
Промокоды Тефаль
Промокоды Сбермаркет
Промокоды Спортмастер
Постила
Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии