Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 41
можно еще proxy_protocol on; в стриме и соответственно proxy_protocol в листенерах.
тогда бэкенды будут видеть айпи клиента.
неужели 3x-ui не умеет переназначать адреса подключения для клиентов? другие панели вроде бы умеют из коробки (в настройках самой панели).
А дело в том что мы используем не proxy_pass, а grpc_pass дабы получить мультиплекс, т.к. NGINX, как я писал, в него толком не умеет (вообще как я понял у них даже философия такая - одно подключение = один апдейт). Колхоз? Да. Работает? Тоже да.
И, собственно, прокси протокола не будет (насколько я уверен, может я не прав и так работает).
Да и плюс, как я уже написал:
У некоторых наверняка возник вопрос: "так, а зачем возится с блоком http? Нельзя ли просто проксировать сразу на inbound?" Можно. НО: у вас по дефолту идёт ответ 404, да и нельзя кастомизировать страницу 404, а если у вас большой легитимный сервис, это может стать реальной проблемой. А ещё работает только режим stream-one, не packet-up или stream-up.
Изменено: чтобы работал прокси-протокол нужно соединение TCP (Raw), а у меня XHTTP.
И да, Host у меня стоит т.к. я его специально добавляю NGINX-ом
UPD: извиняюсь, забыл про sockopt-ы.
Sockopt там можно включить proxy protocol.
Без proxy protocol можно обойтись установив forwardfor заголовки
В haproxy, XHTTP работает в AUTO есть поддержка всего.
В haproxy так же я реализовал и reality с xtls и steel oneself, нужно два домена. Два фронтеда, в tcp соответственно ssl passthrough, и http там, xhttp и fallback, может быть doh ещё.
я вам (наверно всем) кратно поясню что такое Proxy_protocol в tcp. вдруг кто не знает. совсем простыми словами, прошу не докапываться тех кто знает:
на уровне сети у вас может быть просто tcp и tcp в режиме прокси. они не совместимы и нужны когда в стыке соединения надо вкрячить маршрутизацию. например логическую, как прокси пасс и grpc пасс или балансинг соединений на уровне tcp.
оно в идеале ВКЛ на пересыл (не на прослушивание!) на первом интерфейсе где вы начали что-то ковырять, и ВЫКЛ на последнем (где оно пошло дальше).
чтоб везде в логах был адрес клиента не 127.0.0.1, надо вот включить. типовая цепочка включения в серверах начинается с proxy_protocol on; в стриме (не в листенере) или если это иксрей, то с xver 1 где-то в аутбаунде, и заканчивается в листенере чего-то у вас. либо это локальный нгинкс, который слушает и принимает его (proxy_protocol в listen у локального нгинкса или в листенере иксрей).
если торренты блочите, например, то оно в целом по ip блочит в основном (клиентов).
я еще и не туда отправил. прошу прощения @ki11j0y
и grpc_pass уже вроде прям хедерами начинает слать. но если в каком-то приложении надо получать клиентский айпи, то хедеры все равно надо будет слать и до хедеров должен быть еще и прокси пасс, чтобы у приложений во всех на свете логах был не 127.0.0.1, если у вас это приложение (чьи логи) само видит клиентов не на внешнем порту 443. если делаете tcp стримы, то клиент tcp стрима это 127.0.0.1 (или адрес перенаправляющего сервера в сети)
так grpc_pass бэкенд делает. там хедеров достаточно. чтобы работало Proxy_protocol должен быть включен в стриме (не в листенере, а для пересыла) и в листенере бэкенда с grpc_pass (точнее всех бэкендов)
ну и я больше про реврайт хоста в подписке писал. это панели обычно умеют из коробки. хост подписки если не переназначается в панели, может браться из соответствия в хостах например. переназначение внешнего адреса таким приложениям нужно априори и если его там нет, это косяк панели (мне лень ставить эту панель, у меня других хватает). базовый минимум - соответствие внешнего айпи днс имени сервера.
и даже если не умеет, можно в нгинксе хедер править просто в http {}
map $upstream_http_profile_web_page_url $new_header {
"" "";
"~^http://localhost/(.*)$" "https://DOMAIN1.COM/$1";
"~^http://DOMAIN1.COM/(.*)$" "https://DOMAIN1.COM/$1";
}
и в локейшен подписки
proxy_hide_header profile-web-page-url;
add_header profile-web-page-url $new_header;ну и что у вас там пишет вписать в переназначение.
это если панель в подпискее херню выдает.
а security=none во всех панелях исправляется обычно в свойствах инбаунда в панели (клиентского). там обычно помимо листенера есть еще и инбаунд. и должно быть в листенере security none, а в инбаунде security tls (отдельная настройка того что получают клиенты).
это панель довольно старая (в смысле давно есть), и я почему-то уверен что там где-то есть настройки инбаунда, потому как сервису даже если он чисто на один сервер, инбаунд клиентам переназначать надо уметь в настройках.
Насчёт rewrite host-а - да, так можно сделать. Я просто поленился.
а security=none во всех панелях исправляется обычно в свойствах инбаунда в панели (клиентского). там обычно помимо листенера есть еще и инбаунд. и должно быть в листенере security none, а в инбаунде security tls (отдельная настройка того что получают клиенты).
Если найдёте - огромное спасибо вам. Потому что я не нашёл.
вообще и я не нашел. попробовал поставить и не нашел. очень странно, видимо не очень дружественно настроенная к стоять за нгинксом иксрее панель. настройки адреса подписки в настройки-> подписка есть, и даже /path можно задать длинный для подписки, а вот переназначения адреса инбаунда нет вроде. т.е. он принципиально только то на чем буквально слушает выдает клиентам.
я бы наверно разработчиков тикетом замучил и они бы меня забанили, если бы я 3x-ui использовал.
это получается там из коробки нельзя кучу инбаундов на одном 443 иметь? стиранно. у меня все равно ощущение что я не нашел, хотя там и настроек то не так уж и много разных.
можно все равно в нгинксе попробовать что-то вроде этого для пути подписки добавить (возможно нужны кавычки). и вместо sub_filter_types *; application/json text/json и другие нужные, но это надо знать/смотреть какие там.
location /sub/ {
sub_filter_types *;
sub_filter 127.0.0.1:1000 ip_фактического_входа:443;
sub_filter security=none security=tls;
sub_filter_once off;
}если кто-то вдруг решит включать прокси протокол, то:
на листен самого стрима НЕ надо. должен быть
stream {
server {
listen 443;
ssl_preread on;
proxy_pass $backend;
proxy_protocol on;
}
}и бэкенды
server {
listen <ПОРТ1> ssl proxy_protocol;
}так в логе бэкенда будет айпи клиента и иксрей тоже видит айпи клиентов, но ему надо в инбаунд для этого “acceptProxyProtocol”: true в “streamSettings” -> "sockopt"
{
"tag": "mylistener",
"listen": "127.0.0.1:порт",
"protocol": "vless"
"settings": {},
"streamSettings": {
"sockopt": {
"acceptProxyProtocol": true
}
}обратите внимание что т.к. включается прокси протокол на уровне листенера/инбаунда, всё что вы настраиваете в апстримах, получит айпи клиента. и соответственно у апстримов в листенерах должен быть прокси протокол включен (у всех).
ну и для любителей пооптимизировать листенер можно и в unix socket запихнуть, так быстрее, но это вы пишете в файл со всеми вытекающими минусам для контейнеров.
волюм для рамдиска под сокет в docker-compose
volumes:
xray-sock:
driver: local
name: xray-sock
driver_opts:
type: tmpfs
device: tmpfs
o: size=4k,nosuid,nodevи в волюм обоим контейнерам нгинкс и иксрей. добавить, а не заменить весь volumes
volumes:
- xray-sock:/opt/run/xray/:rwминусы:
если не на рамдиске, в случае краша сервера (типа выключения по питанию физического хоста, а не вм), иксрей может не стартануть листенер (как и нгинкс). у меня были тикеты и туда и туда даже.
плюсы:
нет кучи слушающих портов на вм.
минует сетевой стек
ps:
извините что влез.
забыл еще.
чтобы нгинкс проставлял айпи, надо в блок сервер (который принимает proxy_protocol, т.е. бэкенд) вписать еще откуда брать айпи.
server {
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
real_ip_recursive on;
}в случае с юникс сокет листенерами вместо "127.0.0.1" должно быть "unix:"
А чем плохо выставить фронтом xray, а уже после него fallback nginx?
Fallback только TCP (RAW) подключение, а так можно и gRPC, и XHTTP.
Xray видит path, alpn. Можно обойтись без nginx на самом деле
чтобы видеть path, ему нужно делать ssl терминацию, если ssl терминацию делает го приложение, а не нгинкс, это несколько заметно при анализе.
Кстати, не несколько, а ого-го как, что это не стандартный openssl. По этому принципу банят(не у нас пока что) openconnect там gnutls
да, спасибо это было скорее литературное преуменьшение :)
нгинкс иксрею архитектурно полезен как сервер стрима (балансить до инбаунда) или сразу делать ssl-терминацию (на нгинксе до иксрей).
xhttp+reality сейчас самый модный как раз потому что там нет ссл терминации на вообще у впна внешней (в смысле впну как надо при помощи живого веб-сервера делает все равно веб-сервер, но с изменениями и сам), при этом ссл терминацию делает нгинкс (или таргет, если это под внешний сайт). xhttp+tls в целом то же самое, но тут есть ссл терминация и у впна со стороны нгинкса, которой нельзя манипулировать. С ней можно что-то делать без того чтобы го приложение делало ссл терминацию у чего-либо (нгинкс же донор для ссл-терминации как раз).
это я второй раз за день справкой по настройке панелей решил поделиться с человеком, который судя по всему и сам умеет. еще раз извините, @ki11j0y
ладно, интернета пока у меня временно не планируется ближайшее время, так что надеюсь отстану я со своими комментариями от всех.
извините, я наверно не допер что вы тут реалити и имели в виду. помимо ссл терминации на го есть еще реалити. если сэфлстил (под свой же нгинкс), то должно быть не видно ничего подозрительного по идее (я сам трафик не анализировал, но вроде работает)
Self-steal вроде как тоже заметен, если у вас собственный DNS. Тоесть если вы стучитесь сами на себя "а кто такой __?", и сами к себе обращаетесь - это подозрительно. Не проверял сам, но говорили что у них отлетало.
nano /etc/hosts поможет от этого. и в целом некоторые панели (не из поста - 3xui не ставил) нормально домен начинают отдавать когда там прописано соответствие домена, так что иметь домен в хостах тоже это норм практика.
это в принципе.
а в случае с Reality и сэлфстилом у вас дест прописывается как айпи (127.0.0.1) или юникс сокет. если вы туда вписали домен, то по домену (и ресолвинг соответственно) идет потому что вы туда фигню вписали.
это не https подключение, это реалити и домен там нужен только в servernames
По тексту: Панель предложит сертификат на 90 дней от Let's Encrypt.
Это и есть ответ на то, как получить сертификат от Cloudflare?
Короче, это я жёстко тупанул. Дело в том что я перепутал сертификаты от Cloudflare и Cloudflare Origin Certificates. Первое это полноценный SSL за 10$, второе - только валидно при оранжевом облаке. В итоге вырезал тот фрагмент потому что... через оранжевое облако не проксируем. Спасибо что нашли недочёт, вырежу упоминания о фрагменте.
"И самая главная проблема "раскрытия" серверов - простукивание по портам, а также слепки. "
Ох уж эти нейронки 😉. И если уж про этой теме говорить - от куда такая информация? Кто-то исследование проводил? На сколько я знаю в России от Reality вообще толку нет. Dpi сертификаты не проверяет. А крупные vpn сервисы вообще не парятся. В качестве маскировочного sni указывают rbc.ru и пох.
Жалко, конечно, что нынче нейротекст от живого фиг отличишь, но я не нейронка :). А эксперименты (да, маленькие) но были. К сожалению со своего опыта особо не могу сказать, продал родину за Бургер ещё до обсуждения белых списков. Но вот опыт других, особенно подчеркну что многие за Уралом.
По словам друга из ЕКБ: все мои (именно мои, друг это клиент) REALITY сервера (в том числе Беларусь и Армения) которые маскировались под api-maps.yandex.ru (и с неприкрытой панелью, т.к. я ещё тогда был зелёный) - отлетели все через недельку у него. У жителей МСК и СПБ (и областей) проблем не было. Сервера с прикрытой панелью уже были более долгоживущими - где-то месяц простояли. А финляндия которая работает по схеме выше (т.к. у меня ещё на ней крутится реальный проект) - живёт практически у всех.
Конечно не уверен что дело именно в панели, да и то у меня пользуется человек 10 - так что за чистоту результата не могу ручаться. Может подсеть у кого банили (хотя хостинги там разные), и меня задело, а может у челика из РКН нос зачесался xD.
А крупные vpn сервисы вообще не парятся. В качестве маскировочного sni указывают rbc.ru и пох.
Ну они берут количеством, т.к. деньги есть, и меняют серверы (либо IP) как перчатки. Я так не могу.
meredian deployВсё настроит всё сделает, и за обновлениями следить будет
Подскажите по архитектуре. Планирую на VPS кроме 3x-ui установить еще HTTPS-прокси с авторизацией для удобного доступа через браузерное расширение (сейчас использую dumbproxy, но готов перейти на другое решение) и Telemt. Все через tls с доменными сертификатами.
Что выбрать в качестве обратного прокси и как вообще весь этот зоопарк увязать?
Доброго дня всем!
Предлагаю автору и другим понимающим рассмотреть как это реализовано у mozaroc.
Предлагаю автору и другим понимающим рассмотреть как это реализовано у mozaroc.
Меня кабы всё устраивает, всё хорошо, но мне нужно было дополнительно прокинуть в 3x-ui ещё пару протоколов, но не хватило знаний. Так же тоже была идея привязать два домена к серверу. (был печальный опыт с www.noip.com). Пытался всё воплотить с помощью нейронки, но получился какой то бег по кругу, в результате пришлось всё грохнуть.
Пытался написать ютуберам в Ютубе тут и тут, чтоб они сделали видео и разжевали как это сделать, но ни один не ответил. ((
Так, что прошу автора и других заинтересованных, у кого есть время и желание, рассказать как это можно реализовать.(по какому принципу и как дополнительно прокинуть в 3x-ui-pro от mozaroc ещё пару других протоколов и увязать это всё через NGINX с добавлением второго домена для подстраховки)
А ещё могут быть нюансы с proxy pass nginx, мне из-за особенностей и обилия серверов проще было перед всем этим делом поставить ещё HAproxy, но у меня там так же openconnect сервер и ряд сервисов подняты
Рассматриваю тоже сделать HAProxy перед этим всем. Потому что grpc_pass это колхоз.
proxy_pass и grpc_pass это функция http сервера. там всего 2 варианта - слать tcp (то что делает stream в нгинксе) и работать веб-сервером и делать то что веб-сервер умеет (например grpc_pass). хапрокси точно так же работает - там тоже свой стрим и свой http сервер. только хапрокси это больше балансировщик, чем нгинкс, а нгинкс наоборот больше http сервер. нахер вам хапрокси, если в конце все равно есть нгинкс?
если вы на хапрокси ждете чего-то принципиально отличного от нгинкса, то вы наверное зря ждете.
Ну, надо понимать что у нас не gRPC, а XHTTP.
нахер вам хапрокси, если в конце все равно есть нгинкс?
У HAProxy с мультиплексом проблем нет. Так что колхозить ничего не нужно, да и семантически всё правильно (и packet-up режим будет работать, т.к. будет proxy_pass, а с NGINX надо выбирать - колхозить с grpc_pass, или делать proxy_pass и потерять мультиплекс).
А в конце NGINX действительно останется.
Если что под "семантически всё правильно" я про application/http вместо application/grpc. Естественно 4-му уровню пофиг на то какие там биты и байты идут, но надо понимать что это просто везение, а не фича.
нафиг вам мультиплекс, если прокси-пасс локальный? в том плане что мультиплекс между нгинксом и клиентом никуда не делся, а между 127.0.0.1 и 127.0.0.1 и http/1 норм работает.
нгинкс свежий умеет делать proxy_pass через http/2
Лень делать пост...
Вот пошаговый гайд как с ноля поднять нгинкс для автополучения и автообновления сертификатов через certbot и балансировки инбаундов иксрей.
Создаем папку для контейнера и композ-файл:
mkdir /opt/nginx && cd /opt/nginx && nano docker-compose.ymlСкрытый текст
services:
nginx:
image: nginx:mainline-alpine
restart: always
container_name: nginx
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ./certbot/www/:/var/www/certbot/:ro
- ./certbot/conf/:/etc/letsencrypt/:ro
- ./log/:/var/log/nginx/:rw
network_mode: host
certbot:
image: certbot/certbot:latest
container_name: certbot
volumes:
- ./certbot/www/:/var/www/certbot/:rw
- ./certbot/conf/:/etc/letsencrypt/:rw
network_mode: hostсоздаем конфиг нгинкса (без ссл, т.к. сертификатов пока нет):
nano nginx.confСкрытый текст
user root;
worker_processes auto;
error_log /dev/null crit;
pid /run/nginx.pid;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
http {
access_log off;
server {
listen 80;
location /.well-known/acme-challenge { root /var/www/certbot; }
location / { return 301 https://$host$request_uri; }
}
}далее стартуем nginx и проверяем что порт 80 стартанул
docker compose up -d nginx
ss -tulpnтеперь у нас есть нгинкс, который слушает на 80 порту, редиректит все на https (которого на сервере пока нет) и отдает содержимое папки ./certbot/www/ по пути /.well-known/acme-challenge на веб-сервере
теперь можно выпустить бесплатный сертификат от letsencrypt через certbot (MYDOMAIN.RU заменить на днс запись, которая ссылается на данный сервер). порт 80 должен быть открыт в фаерволе.
docker compose run --rm certbot certonly --webroot --webroot-path /var/www/certbot/ --dry-run -d MYDOMAIN.RUесли ошибок нет, в команде нужно убрать --dry-run и выполнить еще раз. dry-run - тестовый запуск. рекомендуется выполнять проверки с этим ключом, чтобы сервера letsencrypt не забанили вас за слишком большое количество неудачных попыток выпусков в случае если у вас таковые будут.
если все хорошо, то создаем скрипт автообновления серта где-нибудь (я пихаю все в /opt)
nano /opt/cert.sh/usr/bin/docker compose --project-directory /opt/nginx run --rm certbot renew
/usr/bin/sleep 30
/usr/bin/docker exec -t nginx nginx -s reloadдалее делаем файл исполняемым
chmod +x /opt/cert.shтеперь редактируем crontab
EDITOR=nano crontab -eи добавляем туда строку:
0 5 1,15 * * /opt/cert.shтеперь сервер в 5 утра 1 и 15 числа месяца будет пробовать обновить серт если тот скоро истекает.
Конфиги nginx.
пример конфигурации нгинкс с балансировкой нескольких сни на разные инбаунды иксрея.
базовая конфигурация без unix socket но с селфстилом.
нгинкс слушает на 443, в зависимости от sni распределяет соединения по upstream серверам.
upstream это везде нгинкс (кроме апстрима drop).
upstream self-backend - инбаунд иксрея, где настроен сэлфстил. этот инбаунд настроен на реалити с дестом в 127.0.0.1:11000
ВНИМАНИЕ: у сервера стрим включен proxy_protocol, следовательно его нужно включить на инбаунде иксрей на прием). У инбаунда делающего реалити на этот же самый нгинкс (на 11000) нужно выставить xver 1 (отправлять прокси протокол)
Скрытый текст
user root;
worker_processes auto;
error_log /dev/null crit;
#error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
stream {
map $ssl_preread_server_name $backend_name {
MYDOMAIN.RU self-backend;
ya.ru ya-backend;
music.yandex.ru music-backend;
default drop-backend;
}
upstream self-backend { server 127.0.0.1:10000; }
upstream ya-backend { server 127.0.0.1:10001; }
upstream music-backend { server 127.0.0.1:10002; }
upstream drop-backend { server 127.0.0.1:11001; }
server {
listen 443;
proxy_protocol on;
proxy_pass $backend_name;
ssl_preread on;
}
}
http {
server_tokens off;
access_log off;
# access_log /var/log/nginx/access.log;
server {
listen 80;
location /.well-known/acme-challenge { root /var/www/certbot; }
location / { return 301 https://$host$request_uri; }
}
server {
listen 127.0.0.1:11000 ssl proxy_protocol;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
real_ip_recursive on;
http2 on;
ssl_certificate /etc/letsencrypt/live/MYDOMAIN.RU/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/MYDOMAIN.RU/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_early_data on;
ssl_stapling off;
server_name MYDOMAIN.RU;
location / {
limit_except GET { deny all; }
return 403;
}
}
server {
listen 127.0.0.1:11001 ssl proxy_protocol;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
real_ip_recursive on;
ssl_reject_handshake on;
ssl_protocols TLSv1.2 TLSv1.3;
}
}на всякий случай еще конфиг без сэлфстила (и без ссл\сертификата соответственно)
Скрытый текст
user root;
worker_processes auto;
error_log /dev/null crit;
#error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
stream {
map $ssl_preread_server_name $backend_name {
ya.ru ya-backend;
music.yandex.ru music-backend;
default drop-backend;
}
upstream ya-backend { server 127.0.0.1:10001; }
upstream music-backend { server 127.0.0.1:10002; }
upstream drop-backend { server 127.0.0.1:11001; }
server {
listen 443;
proxy_protocol on;
proxy_pass $backend_name;
ssl_preread on;
}
}
http {
server_tokens off;
access_log off;
# access_log /var/log/nginx/access.log;
server {
listen 127.0.0.1:11001 ssl proxy_protocol;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
real_ip_recursive on;
ssl_reject_handshake on;
ssl_protocols TLSv1.2 TLSv1.3;
}
}так вообще никакого ссл нет. такой вариант нужен тем у кого нет сэлфстила, но есть куча реалити на разные sni и хочется это всё таки на 443 все иметь.
для простоты в конфигах у апстримов просто порты на 127.0.0.1. но я лично использую unix socket.
вот для сравнения такой же nginx.conf на unix socket (с сэлфстилом)
Скрытый текст
user root;
worker_processes auto;
error_log /dev/null crit;
#error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
stream {
map $ssl_preread_server_name $backend_name {
MYDOMAIN.RU self-backend;
ya.ru ya-backend;
music.yandex.ru music-backend;
default drop-backend;
}
upstream self-backend { server unix:/opt/run/xray/xray-self.socket; }
upstream ya-backend { server unix:/opt/run/xray/xray-ya.socket; }
upstream music-backend { server unix:/opt/run/xray/xray-music.socket; }
upstream drop-backend { server unix:/run/nginx-drop.socket; }
server {
listen 443;
proxy_protocol on;
proxy_pass $backend_name;
ssl_preread on;
}
}
http {
server_tokens off;
access_log off;
# access_log /var/log/nginx/access.log;
server {
listen 80;
location /.well-known/acme-challenge { root /var/www/certbot; }
location / { return 301 https://$host$request_uri; }
}
server {
listen unix:/opt/run/xray/nginx.socket ssl proxy_protocol;
set_real_ip_from unix:;
real_ip_header proxy_protocol;
real_ip_recursive on;
http2 on;
ssl_certificate /etc/letsencrypt/live/MYDOMAIN.RU/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/MYDOMAIN.RU/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_early_data on;
ssl_stapling off;
server_name MYDOMAIN.RU;
location / {
limit_except GET { deny all; }
return 404;
}
}
server {
listen unix:/run/nginx-drop.socket ssl proxy_protocol;
set_real_ip_from unix:;
real_ip_header proxy_protocol;
real_ip_recursive on;
ssl_reject_handshake on;
ssl_protocols TLSv1.2 TLSv1.3;
}
}Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой гайд как на одном и том же сервере иметь и панель 3X-UI за NGINX, и свой сервис