Nginx *

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

Если у тебя тоже, %USERNAME%, что-то внутри начинает грустить, глядя на белый экран с текстом “Not Found.*Nginx”, то знай - ты не один. Сейчас мы разберём, как прикрутить к ним весёлые обои, от простого до Kubernetes.

В процессе администрирования веб‑сервера наступает момент, когда нужно протестировать производительность решения, оптимизировать настройки, проверить гипотезу. Для решения этих задач нужно выбрать правильный инструмент для бенчмарка, о чём и будем говорить в этой статье. Все примеры будут разобраны на основе сервера Angie, но могут применяться и к другим продуктам. В этой статье будут освещены простые и доступные утилиты для оперативных тестов. 

Я Михаил — создатель и главный разработчик системы вэб приложений. Второй участник проекта — Владимир — разработчик мобильных версий и ответственный за SEO оптимизацию.

В 2026 для VPN нужна маскировка. А нет никакой лучшей маскировки, чем уже работающий легитимный сервис. Силами NGINX-streams и HTTP2 это сделать довольно легко.

Изображения играют важную роль в любом веб‑приложении. Это могут быть элементы оформления интерфейса или основной контент сайта. В любом случае, перед разработчиками и администраторами стоит задача эффективной работы с картинками и в этой статье мы рассмотрим решения, которые реализуются веб‑сервером Angie.

Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском

Очередной генератор nginx-конфигов? Нет. Ну, почти нет.

Данный таск был частью 5 сезона CTF, который проходил на площадке ACLabs. Машина необычная с увлекательным сюжетом и интересными уязвимостями.

Условие задачи:

Борис — старый почтовый голубь. Катя, его голубка, улетела к наглому Воробью. Три дня Борис пил дешёвое пойло и строчил план мести. Теперь этот план у тебя. Помоги Борису пробраться в цифровое гнездо Воробья, украсть его аккаунт и стать рутом. Следуй за пьяными записками — там всё сказано и даже больше. Внимание, стенд будет полностью готов только по истечении обратного времени отсчета, даже если адрес появился раньше!

Цепочка атаки

Атакующая цепочка «PigeonsRevenge» комбинирует одну реальную критическую CVE (Webmin 1.910 — CVE-2019-15107, 9.8 CRITICAL) с набором классических техник ATT&CK: активная разведка → port knocking → эксплуатация публичного приложения → Metasploit reverse-shell → туннелирование Ligolo-ng → инъекция через переменную окружения в кастомный бинарник → обход фильтра табуляцией → закрепление с root-привилегиями.

Ваши логи забиты попытками входа в .env, .git и wp-login.php? Пока бот стучится в Nginx, ваш сервер уже тратит драгоценные ресурсы. Я решил перенести фильтрацию в ядро Linux и делюсь рабочим кейсом эшелонированной обороны на базе ipset и CrowdSec.

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

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

Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt

Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.

WP умер, перевёл все сайты на OpenClaw

Раньше часто использовал WordPress с кучей плагинов для создания сайтов и лендингов. Сейчас поставил DarwinClaw на чистую машину Ubuntu и сказал ему сделать всю инфраструктуру для сайтов. Он поставил nginx + node.js.

Потом попросил перенести сайты, указав ссылки на них. Он создал все сайты.

Попросил добавить git и репозиторий для хранения этих сайтов. То есть всегда можно быстро откатить изменения.

Теперь полностью управляю этим зоопарком лендингов через TG команды типа:

Убери с сайта X вот это

Добавь на сайт Y вот то

Поменяй стиль сайта Z на …

Откати последние изменения на сайте XM

Замени икноку на сайте XS на более современную

Собери статистику по заполнению форм с сайтов X, Y, Z в формате

Раньше это либо делали люди за деньги, либо WP с его тяжёлой инфраструктурой, теперь всё делает бот на OpenClaw.

Привет, Хабр!

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

В той статье я предложил Хабру попытаться сломать сервер моего мессенджера. Было потно, но мы выстояли. Спасибо всем, кто участвовал!

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

Сервер лагает. Смотришь на диск — df -h говорит 95% занято. Запускаешь du -sh /* — в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.

Это не баг и не магия. Это фундаментальная особенность того как Linux работает с файлами. Разберём почему так происходит и как это чинить за две команды.

Почему я решил сделать свой платёжный бот

Я просто хотел принимать платежи и донаты в своём Telegram-канале. Ничего сложного: кинул ссылку — получил деньги. Но когда начал смотреть существующие сервисы (Трибьюн, BotPay и подобные), столкнулся с одним и тем же: регистрация, паспорт, ИП, привязка карт. Мне это было неприятно — как будто чужой дядька лезет в интимные места.

Я не хотел светить данные, не хотел оформлять юридическое лицо, не хотел возиться с налоговой. Хотел просто продавать мануалы и принимать донаты, используя встроенную валюту Telegram — Stars.

Так родилась идея сделать своего бота: анонимного, без регистраций, без паспортов. Чтобы любой человек, у которого есть Telegram, мог создать товар, кинуть ссылку и получить деньги.

Привет, меня зовут Камиль, мне 23, я из Москвы и работаю аналитиком/инженером данных в банке. И не смотря на душную итшную работу, у меня есть еще более душное увлечение: homelabbing. Это хобби, когда люди создают у себя дома небольшие (кто-то и большие) серверные лаборатории и переносят часть личных задач, которые обычные люди решают сторонними сервисами, туда.

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

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

Если такой туториал уже был на Хабре — не вините строго, я не нашел, и мне, на удивление, понадобился большой бубен и пол дня чтобы настроить сабж.

Вводные:

1) у вас есть крохотная виртуалка на которой крутится nginx и пара сайтов. Конечно https и скорее всего let's encrypt — короче стандартный набор рядового девелопера.

2) вы бы хотели поднять телеграм-прокси, но так чтобы трафик на него был максимально похож на обычный https, а это значит 443 порт — но вы хотите чтобы nginx и ваши сайты продолжили работать как и раньше.

Если это про вас и для вас — вот объяснение механизма и небольшой туториал.

Начну с небольшого вступления: зачем вообще нужен .htaccess файл?

.htaccess — это конфигурационный файл, который использует веб‑сервер Apache для задания специфических настроек для каждой отдельной папки сайта. Благодаря ему можно:

24 контейнера на одном VPS за $30/мес: Elasticsearch, Redis, MySQL, nginx, headless Chrome, llama.cpp и еще 18 сервисов. Реальные docker-compose файлы, конфиги nginx, потребление RAM каждого контейнера и честный список того, что не работает. Сравнение стоимости с managed-сервисами в облаке.

Наверняка вы слышали о новых версиях HTTP — второй и третьей. Что за этими версиями? Зачем они были разработаны? Чем они отличаются от классического HTTP/1.1 и где могут быть полезны? Какие настройки предоставляет веб‑сервер Angie для этих протоколов? Все эти вопросы мы будем разбирать в этой статье.

Начнём с краткой истории развития протокола HTTP.

Привет, я Александр Хренников, руководитель DevOps-юнита в KTS.

Нам тут, оказывается, 5 лет стукнуло. Точнее, нашему блогу на Хабре. Подарков мы не дождались, так что решили сами вручить их вам. Дарить будем футболки с нашим фирменным принтом — Котзиллой. Это как Годзилла, только кот.

Но подарок получат не все, а десять DevOps-инженеров, которые справятся с нашим испытанием быстрее остальных. Суть проста: мы даем вам тестовый стенд с кластером Kubernetes с ArgoCD и отдельный GitLab-сервер. В ArgoCD добавлено приложение — простой Nginx, обернутый в Helm-чарт. И оно не запускается. Надо запустить.

DevOps-челленджи мы проводим не впервые: уже были этот, этот и еще несколько до них. Опытные участники уже знают механику, а для новых энтузиастов я расскажу ниже, как все устроено.