[{"data":1,"prerenderedAt":258},["ShallowReactive",2],{"article-58-hi":3,"related-58":83,"ArticleBody_0pOP0fxvvV4anUB6eySJpr3peXgFfehyyI5uqZqEI":253},{"id":4,"title":5,"slug":6,"content":7,"metaTitle":5,"metaDescription":8,"coverUrl":9,"views":10,"likes":11,"createdAt":12,"updatedAt":13,"category":14,"tags":23,"author":9,"tableOfContents":28,"locale":9,"translated":81,"indexable":82},58,"Отказоустойчивый трансграничный L7-каскад","otkazoustoychivyy-transgranichnyy-l7-kaskad","**Отступление для новичков.**\n\nПривет!\n\nЕсли ты только что арендовал свой первый VPS (виртуальный сервер) или только планируешь это сделать, и открыл этот гайд, то, скорее всего, тебе нужно понять текст написанный ниже в гайде. \n\nДля понимания предлагаю воспользоваться нейронкой и подготовил для тебя промт.\n\n```\nТы — терпеливый и понятный IT-наставник. Я — абсолютный новичок: я только что арендовал (или планирую арендовать) свой первый VPS-сервер. Я ничего не понимаю в сетях, протоколах, DPI, L3/L7 уровнях, репликации баз данных и законах о персональных данных. \n\nТвоя задача: когда я скину тебе текст технического гайда, ты должен:\n1. Полностью проигнорировать сложные разделы (про юрисдикции, GDPR, 152-ФЗ, PostgreSQL, VRRP, Keepalived, DNS Failover) — это не для меня на старте.\n2. Вытащить из текста только то, что нужно для САМЫХ ПЕРВЫХ ШАГОВ: как зайти на сервер, что базово включить, чтобы всё просто работало.\n3. Объяснять всё максимально простыми словами, используя бытовые аналогии (как с машиной, квартирой, почтой и т.д.).\n4. Давать готовые команды, которые можно просто скопировать и вставить, с коротким пояснением, что каждая из них делает «на пальцах».\n5. Не пугать меня сложностью. Подбадривать.\n\nЕсли ты понял задачу, ответь одной фразой: «Принял. Скидывай текст гайда, я переведу его на язык первых шагов для новичка».\n```\n**Успехов!**\n\n# Отказоустойчивый трансграничный L7-каскад (Россия → Германия): Архитектура и реализация\n\n## Введение\nПостроение распределенной инфраструктуры, охватывающей несколько юрисдикций (в данном случае — Россию и Германию), выходит за рамки чисто сетевых задач. Такой проект требует глубокого понимания не только протоколов и маршрутизации, но и вопросов игнорирования систем глубокой проверки пакетов (DPI), обеспечения отказоустойчивости, а также соблюдения требований законодательства о защите данных.\n\nВ данном руководстве мы разберем архитектуру гибридного L7-каскада, который решает три ключевые задачи:\n1. Обход DPI-блокировок в РФ.\n2. Создание отказоустойчивой Active-Active конфигурации на бюджетных VPS.\n3. Обеспечение юридической чистоты при работе в двух конфликтующих юрисдикциях.\n\n---\n\n## 1. Выбор уровня взаимодействия: L3-туннель и L7-проксирование\nЧтобы два сервера могли взаимодействовать друг с другом так, словно они находятся в одной локальной сети, необходимо создать виртуальный коммутатор и подключить к нему их сетевые интерфейсы. Однако эта операция выполняется на уровне гипервизора хостинг-провайдера и недоступна пользователям стандартных VPS.\n\nДля достижения аналогичного эффекта применяется технология туннелирования. В рамках данной архитектуры оптимальным и наиболее эффективным решением является использование протокола AmneziaWG для создания L3-туннеля. Принцип его работы заключается в создании специального виртуального сетевого интерфейса (`awg0`), который шифрует IP-пакеты и передает их через UDP-соединение на другой сервер. Обязательным условием для этого является наличие у обоих серверов публичных IP-адресов, предоставляемых хостинг-провайдером.\n\nЭтот туннель будет служить связью для внутренних служебных компонентов VPS (например, между серверами в Москве и Новосибирске). Для трансграничного клиентского трафика (Россия → Германия) рассмотрим иной подход.\n\n---\n\n## 2. Обход DPI-блокировок: Выбор протоколов и маскировка трафика.\nДля обеспечения работоспособности трансграничного каскада критически важно преодолеть систему глубокой проверки пакетов (DPI). Оборудование ТСПУ (Технические средства противодействия угрозам) установлено не только на международных узлах связи. По закону оно размещается на «аплинках» почти всех дата-центров и хостинг-провайдеров, а также на крупных точках обмена трафиком между городами.\n\nВ условиях ужесточения блокировок могут появиться новые методы атак на протоколы туннелирования, такие как анализ специфических паттернов рукопожатия TCP. Это подчеркивает важность гибкости архитектуры: в случае компрометации основного метода необходим «План Б».\n\n### Стратегия выбора протоколов\n\n**Основной метод: VLESS + REALITY**\nНа текущий момент это наиболее эффективное решение. REALITY имитирует TLS-соединение с реальным сайтом (например, `google.com` или `microsoft.com`), подставляя его имя в качестве SNI (Server Name Indication). Это делает трафик практически неотличимым от легитимного запроса обычного браузера, сводя на нет возможность блокировки на основе анализа сигнатур.\n\n**Резервный метод (План Б): VLESS + WebSocket + TLS через CDN**\nЕсли REALITY перестанет работать, трафик можно проксировать через CDN-провайдера (например, Cloudflare). В этом сценарии трафик от клиента идет на CDN, который выступает в роли обратного прокси. Сервер CDN, имея собственный легитимный TLS-сертификат, шифрует трафик и передает его дальше. Для систем ТСПУ этот трафик выглядит как обычное HTTPS-соединение с крупным CDN-провайдером, что делает его практически неуязвимым для DPI.\n\n**Альтернативные технологии:**\n* **Hysteria2 и Tuic**: Современные протоколы на базе QUIC (HTTP/3). Обеспечивают высокую пропускную способность и устойчивость к потере пакетов, но имеют меньшую базу клиентских приложений.\n* **AmneziaWG**: Форк WireGuard с встроенными режимами обфускации, делающими его менее заметным для DPI.\n* **Zapret**: Универсальный инструмент, использующий техники десинхронизации пакетов (DPI-desync) для «сломa» анализа трафика на стороне провайдера.\n\n### Сравнительная таблица технологий\n\n| Протокол / Технология | Принцип действия | Преимущества | Недостатки | Стабильность в РФ (оценочно) |\n| :--- | :--- | :--- | :--- | :--- |\n| **VLESS + REALITY** | Имитация TLS-соединения с реальным сайтом (SNI-based). | Очень высокая маскировка под легитимный HTTPS. | Потенциальная уязвимость к новым методам глубокого анализа TLS-рукопожатия. | Высокая |\n| **VLESS + WS + TLS (CDN)** | Проксирование трафика через CDN (Cloudflare и др.). | Трафик идет на авторитетный CDN, что гарантирует обход DPI. | Требует настройки CDN, может добавлять сетевую задержку (latency). | Очень высокая |\n| **Hysteria2 / Tuic** | Использование протокола QUIC (UDP, HTTP/3). | Высокая скорость, отличная работа в условиях потери пакетов. | Относительно новые протоколы, меньше поддерживаемых клиентов. | Средняя |\n| **AmneziaWG** | Обфускация стандартного трафика WireGuard. | Привычный интерфейс WireGuard, легкость базовой настройки. | Обфускация может быть менее надежной против целевого анализа, чем REALITY. | Средняя |\n| **Zapret** | DPI-desync (десинхронизация и фрагментация пакетов). | Гибкость, открытый исходный код, не требует серверной части. | Требует тонкой ручной настройки под конкретного провайдера, возможны сбои. | Нестабильная |\n\nДля построения надежной системы следует выбрать основной протокол (например, `VLESS + REALITY`) и держать в резерве альтернативный. Это позволит быстро переключиться на запасной вариант в случае блокировок.\n\n---\n\n## 3. Архитектура нод: Входная и выходная\nВ контексте нашей архитектуры, где российский сервер выступает в роли входной ноды (фасада), а немецкий — в роли выходной, именно на российском сервере должен быть развернут Xray с выбранным протоколом маскировки. Он будет принимать клиентский трафик, маскировать его и отправлять по защищенному каналу в Германию.\n\n### Входная нода (Россия)\nЗадача российского сервера — принять подключение клиента с минимальным пингом, замаскировать его и передать дальше.\n* **Веб-сервер Nginx**: Выступает «фасадом». На сервере разворачивается маскировочный сайт-заглушка.\n* **TLS-шифрование**: Используется валидный SSL-сертификат от Let's Encrypt для вашего домена (например, `vpn.example.com`).\n* **WebSocket (WS)**: При обращении по секретному, заранее сгенерированному пути, Nginx перехватывает соединение и переводит его в WebSocket, передавая поток напрямую в ядро Xray.\n\n### Выходные ноды (Германия)\nЕвропейские серверы занимаются только обработкой «очищенного» трафика, поступившего от российского сервера по внутреннему каналу. Для связи между российской и немецкими нодами внутри каскада отлично подходит легкий Shadowsocks (с шифрованием `chacha20-ietf-poly1305`) или тот же VLESS + REALITY. Поскольку этот внутренний трафик скрыт внутри вашего каскада и не соприкасается с провайдерами конечных клиентов напрямую, требования к его маскировке ниже.\n\nКлиенты из России подключаются к входной ноде по протоколу, маскирующему трафик. Внутренний трафик между российским и немецким серверами уже не является предметом внимания систем DPI, так как он инкапсулирован в TLS и выглядит как обычное HTTPS-соединение. Это полностью решает проблему блокировок на территории РФ и обеспечивает стабильный доступ к зарубежным ресурсам.\n\n---\n\n## 4. Отказоустойчивость: Active-Active и DNS Failover\nНаиболее универсальным, надежным и рекомендуемым для бюджетных VPS решением является использование DNS Failover в связке с архитектурой Master-Master (Active-Active). Эта модель полностью независима от политик конкретного хостинг-провайдера (в отличие от использования Floating IP).\n\nВ данной схеме оба сервера (российский и немецкий) настраиваются как равноправные мастер-узлы. Каждый из них принимает клиентский трафик на свой собственный публичный IP-адрес. DNS-сервер (например, Cloudflare) выступает в роли балансировщика нагрузки первого уровня. Он возвращает клиентам список из нескольких IP-адресов с низким значением TTL (60–300 секунд). Большинство DNS-провайдеров используют алгоритм Round Robin, возвращая IP-адреса в разном порядке, что позволяет равномерно распределять нагрузку.\n\n### Почему мы не используем классический VRRP\nПротокол VRRP позволяет нескольким серверам выступать в роли единого виртуального шлюза с общим виртуальным IP-адресом (VIP). В классическом сценарии узлы обмениваются heartbeat-пакетами через multicast-адреса, но этот подход не работает через интернет.\n\nДля работы через глобальную сеть в Keepalived предусмотрен unicast-режим, но он порождает проблему на уровне ядра Linux. За фильтрацию «чужих» пакетов отвечает параметр `rp_filter` (Reverse Path Filtering). Если он установлен в значение `1` (строгий режим), ядро будет отклонять VRRP-пакеты, ошибочно считая их поддельными. Чтобы заставить unicast VRRP работать, параметр необходимо ослабить (`0` или `2`), что снижает безопасность сервера и может нарушать правила хостинг-провайдера.\n\nИменно поэтому мы отказались от классического переключения VIP-адреса в пользу более надежного механизма — автоматического управления DNS-записями через API.\n\n### Механизм DNS-триггера (Failover & Recovery)\nВ нашей схеме Keepalived не управляет виртуальным IP-адресом. Он используется исключительно как внутренний монитор состояния.\n1. **Обнаружение сбоя**: Скрипт проверки работоспособности (`vrrp_script`) на Node-B обнаруживает, что Node-A недоступен.\n2. **Срабатывание триггера**: Когда `vrrp_script` фиксирует потерю связи, срабатывает директива `notify_fault`, которая запускает внешний bash-скрипт.\n3. **Обновление DNS**: Этот скрипт использует API-токен Cloudflare для выполнения HTTP `DELETE`-запроса. IP-адрес упавшего Node-A удаляется из DNS-записи.\n4. **Переключение трафика**: Через 60–300 секунд (согласно TTL) глобальные DNS-резолверы обновят кэш, и все клиенты будут подключаться исключительно к работающему узлу.\n\n### Процесс восстановления (Recovery)\nКогда Node-A возвращается в строй, его `vrrp_script` снова начинает успешно выполняться. Keepalived фиксирует это и срабатывает `notify`-скрипт, который выполняет HTTP `POST`-запрос к API Cloudflare, добавляя IP-адрес Node-A обратно в DNS-запись. Система автоматически возвращается в режим Active-Active.\n\n> **Примечание**: Данный подход элегантно решает проблему отказа сервиса без необходимости покупать дорогие Floating IP. Единственный его нюанс — задержка переключения трафика, которая напрямую ограничена значением TTL вашей DNS-записи.\n\n### Плюсы и минусы DNS-балансировки\n**Преимущества:**\n* **Полная независимость от хостера**: Не требуется поддержка Floating IP, не нужно менять параметры ядра (`rp_filter`).\n* **Масштабируемость**: В DNS-запись можно добавить не два, а десять и более серверов по всему миру.\n\n**Недостатки (Проблема TTL-задержки):**\nЭтот подход отлично решает проблему внезапного отказа сервиса, но имеет нюансы при плановых работах. Если сервер уходит на обслуживание, его IP останется в DNS-записи, и часть клиентов будет обращаться к «мертвому» адресу до истечения TTL.\n* **Как минимизировать риски**: При планировании технических работ администратор должен вручную удалять IP обслуживаемого сервера из DNS-записи за 5–10 минут до начала работ.\n\n---\n\n## 5. Оптимизация, синхронизация и безопасность\n\n### Синхронизация конфигураций и SSL-сертификатов\nКонфигурационные файлы Xray, Nginx и SSL-сертификаты должны быть полностью идентичны на всех входных нодах. Для автоматизации рекомендуется использовать Ansible или `rsync` по расписанию (cron).\n> **Важно**: Если сертификаты рассинхронизируются, в момент переключения DNS клиенты столкнутся с ошибкой проверки TLS-сертификата (Certificate Mismatch).\n\n### Оптимизация сетевого стека (TCP BBR)\nПоскольку клиентский трафик передается через L7-прокси, критически важна работа сетевого стека. Включение алгоритма BBR позволяет значительно повысить пропускную способность. Добавьте параметры в `/etc/sysctl.conf`:\n```ini\nnet.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr\n```\n*(Примените изменения командой `sysctl -p`)*.\n\n### Базовая безопасность (nftables и Fail2ban)\n* **Файрвол nftables**: Настраивается по принципу «запрещено всё, что явно не разрешено». Открыты только порты `80`, `443` и `22` (SSH рекомендуется перенести на нестандартный порт).\n* **Демон Fail2ban**: Анализирует логи Nginx, Xray и SSH, автоматически блокируя IP-адреса злоумышленников.\n\n---\n\n## 6. Управление данными и юрисдикционные аспекты\nПостроение инфраструктуры, охватывающей Россию и Германию, требует четкого понимания того, как управлять данными и соблюдать локальные регуляторные требования.\n\n### Репликация данных в Active-Active конфигурации\nДля нашей архитектуры оптимальным решением является двунаправленная логическая репликация. Начиная с версии 16, PostgreSQL предоставляет нативную поддержку многоузловой репликации. Каждый сервер выступает одновременно и как издатель, и как подписчик.\n\n**Ключевые преимущества:**\n* **Гибкость**: Можно реплицировать только определенные таблицы (например, справочники), оставляя локальными таблицы сессий.\n* **Низкая задержка**: Логическая репликация быстрее классической физической.\n\n### Разрешение конфликтов\nДвунаправленная репликация имеет риск возникновения конфликтов записи. Для стабильной работы необходимо:\n* **Использование UUID**: Откажитесь от `SERIAL` в пользу `UUID` (или `UUIDv7`), чтобы исключить конфликты первичных ключей.\n* **Разделение диапазонов ID**: Если используются целые числа, настройте непересекающиеся диапазоны для разных узлов.\n* **Стратегия Last-Write-Wins (LWW)**: По умолчанию PostgreSQL применяет эту стратегию на основе времени транзакции.\n\n### ⚖️ Юрисдикционные риски: 152-ФЗ против GDPR\nРФ и ЕС имеют диаметрально противоположные подходы к защите данных.\n\n🇷🇺 **Российская Федерация (152-ФЗ)**\nТребует, чтобы персональные данные (ПДн) граждан РФ хранились на серверах, физически расположенных на территории России. Трансграничная передача возможна только при соблюдении строгих условий.\n\n🇪🇺 **Европейский Союз (GDPR)**\nПДн граждан ЕС не могут передаваться в «третьи страны» без признания «адекватного уровня защиты». Россия не имеет такого статуса. Передача возможна только при использовании Стандартных договорных оговорок (SCCs) и Оценки воздействия на передачу (TIA).\n\n**Правовой парадокс:**\nРоссийский сервер обязан хранить данные россиян, немецкий — защищать данные европейцев. Репликация ПДн между ними нарушает оба закона. Ситуация усугубляется, если в цепочке участвуют компании из третьих стран (например, США с их CLOUD Act).\n\n### Архитектурный вывод: Шардирование по юрисдикциям\nДвунаправленная репликация таблиц с персональными данными между РФ и ЕС юридически невозможна.\nЕдинственное верное решение — шардирование данных:\n* **Локальные ПДн**: Хранятся строго локально (российские пользователи — в РФ, европейские — в Германии). Репликация запрещена.\n* **Глобальные справочники**: Таблицы без ПДн свободно реплицируются между узлами.\n* **Анонимная аналитика**: Агрегированные, обезличенные срезы данных могут безопасно синхронизироваться.\n\n---\n\n## 7. Практические шаги для реализации\nДля развертывания описанной архитектуры необходимо последовательно выполнить следующие шаги:\n\n1. **Аренда и базовая настройка инфраструктуры:**\n   Арендовать два VPS: один в России и один в Германии. На обоих серверах включить TCP BBR, настроить `nftables` и установить `Fail2ban`.\n2. **Настройка DNS и получение API-доступа:**\n   Зарегистрировать домен, подключить Cloudflare. Создать A-запись с обоими IP, установить TTL 60 секунд. Сгенерировать API-токен и получить Zone ID / Record ID.\n3. **Разработка скриптов управления DNS:**\n   Написать скрипты (Bash/Python) для HTTP-запросов к Cloudflare API. Учесть лимиты скорости (1200 запросов в 5 минут) и реализовать retries с экспоненциальной задержкой.\n4. **Синхронизация конфигураций:**\n   Настроить Ansible или cron с `rsync` для синхронизации конфигов Xray/Nginx и SSL-сертификатов между серверами.\n5. **Развертывание L7-проксирования (Xray):**\n   * *Российский сервер*: Установить Xray, настроить `inbound` с VLESS + REALITY. Настроить Nginx как фасад с WebSocket.\n   * *Немецкий сервер*: Установить Xray, настроить `inbound` для приема трафика от РФ и `outbound` для проксирования в интернет.\n6. **Настройка Keepalived и триггеров:**\n   Установить Keepalived на оба сервера. Настроить `vrrp_script` и `notify`-директивы для вызова скриптов обновления DNS.\n7. **Тестирование отказоустойчивости:**\n   Искусственно остановить сервис на одном из серверов и убедиться, что DNS обновляется, а трафик перенаправляется. Проверить обратный процесс восстановления.\n\n---\n\n## Заключение\nАрхитектура, описанная в данном руководстве, по своей сути не предназначена для обработки персональных данных. Её основное назначение — создание отказоустойчивых обходных путей для трафика, где источник и назначение данных не подлежат идентификации.\n\nИспользование серверов в разных юрисдикциях создает непреодолимые правовые барьеры для работы с ПДн. Если бизнес-логика всё же требует обработки чувствительной информации, единственным надежным способом обеспечить реальную суверенность данных является применение криптографии с ключами, контролируемыми пользователем (BYOK/HYOK).\n\nПри декларативном проектировании любых распределенных систем критически важно не только определять технические компоненты, но и четко документировать юрисдикционные ограничения. Архитектура должна быть спроектирована так, чтобы избегать сбора ПДн, либо должны быть предусмотрены строгие механизмы их защиты, соответствующие законодательству обеих юрисдикций.","Отступление для новичков. Привет! Если ты только что арендовал свой первый VPS (виртуальный сервер) или только планируешь это сделать, и открыл этот гайд, то, с",null,92,2,"2026-07-12T10:41:15.861Z","2026-09-01T12:06:47.000Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":19},24,"gaydy","Гайды",0,{"id":20,"value":21,"content":22,"sortOrder":18},23,"obshchee","Общее",[24],{"id":25,"value":26,"content":27},18,"gayd","гайд",[29,32,34,36,38,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79],{"level":30,"text":31},1,"Отказоустойчивый трансграничный L7-каскад (Россия → Германия): Архитектура и реализация",{"level":11,"text":33},"Введение",{"level":11,"text":35},"1. Выбор уровня взаимодействия: L3-туннель и L7-проксирование",{"level":11,"text":37},"2. Обход DPI-блокировок: Выбор протоколов и маскировка трафика.",{"level":39,"text":40},3,"Стратегия выбора протоколов",{"level":39,"text":42},"Сравнительная таблица технологий",{"level":11,"text":44},"3. Архитектура нод: Входная и выходная",{"level":39,"text":46},"Входная нода (Россия)",{"level":39,"text":48},"Выходные ноды (Германия)",{"level":11,"text":50},"4. Отказоустойчивость: Active-Active и DNS Failover",{"level":39,"text":52},"Почему мы не используем классический VRRP",{"level":39,"text":54},"Механизм DNS-триггера (Failover & Recovery)",{"level":39,"text":56},"Процесс восстановления (Recovery)",{"level":39,"text":58},"Плюсы и минусы DNS-балансировки",{"level":11,"text":60},"5. Оптимизация, синхронизация и безопасность",{"level":39,"text":62},"Синхронизация конфигураций и SSL-сертификатов",{"level":39,"text":64},"Оптимизация сетевого стека (TCP BBR)",{"level":39,"text":66},"Базовая безопасность (nftables и Fail2ban)",{"level":11,"text":68},"6. Управление данными и юрисдикционные аспекты",{"level":39,"text":70},"Репликация данных в Active-Active конфигурации",{"level":39,"text":72},"Разрешение конфликтов",{"level":39,"text":74},"⚖️ Юрисдикционные риски: 152-ФЗ против GDPR",{"level":39,"text":76},"Архитектурный вывод: Шардирование по юрисдикциям",{"level":11,"text":78},"7. Практические шаги для реализации",{"level":11,"text":80},"Заключение",false,true,[84,125,138,152,177,191,208,223,237,248],{"id":85,"title":86,"slug":87,"content":88,"description":88,"coverUrl":9,"views":10,"likes":18,"createdAt":89,"category":90,"tags":92,"author":122},89,"Что такое uptime VPS и почему 99,9% - это не 100%","chto-takoe-uptime-vps","Что такое uptime VPS и почему 99,9% - это не 100% == Когда выбирают VPS, одним из первых показателей, на который обращают внимание, становится uptime. Провайдер","2026-08-17T14:22:17.023Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":91},{"id":20,"value":21,"content":22,"sortOrder":18},[93,94,98,102,106,110,114,118],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},19,"pravila","правила",{"id":99,"value":100,"content":101},114,"bezopasnost","Безопасность",{"id":103,"value":104,"content":105},115,"rukovodstvo","Руководство",{"id":107,"value":108,"content":109},116,"instrukciya","Инструкция",{"id":111,"value":112,"content":113},117,"tutorial","Туториал",{"id":115,"value":116,"content":117},119,"ustanovka","Установка",{"id":119,"value":120,"content":121},120,"sovety","Советы",{"id":123,"name":124,"slug":9},109,"serv.host",{"id":126,"title":127,"slug":128,"content":129,"description":129,"coverUrl":9,"views":130,"likes":30,"createdAt":131,"category":132,"tags":134,"author":137},87,"Хостинг API и бэкенд-приложений на VPS","hosting-api-i-bekend-prilojeniy-na-vps","Хостинг API и бэкенд-приложений на VPS == Если вы разрабатываете сайт, мобильное приложение или собственный сервис, рано или поздно возникает вопрос - где разме",94,"2026-08-17T13:52:11.777Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":133},{"id":20,"value":21,"content":22,"sortOrder":18},[135,136],{"id":25,"value":26,"content":27},{"id":111,"value":112,"content":113},{"id":123,"name":124,"slug":9},{"id":139,"title":140,"slug":141,"content":142,"description":142,"coverUrl":9,"views":143,"likes":30,"createdAt":144,"category":145,"tags":147,"author":9},86,"ИИ в технической работе: где помогает, а где нельзя доверять","ii-v-tehnicheskoy-rabote-gde-pomogaet-a-gde-nelzya-doveryat","ИИ в технической работе: где помогает, а где нельзя доверять Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой прое",100,"2026-08-09T09:26:13.317Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":146},{"id":20,"value":21,"content":22,"sortOrder":18},[148,149,150,151],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},{"id":103,"value":104,"content":105},{"id":119,"value":120,"content":121},{"id":153,"title":154,"slug":155,"content":156,"description":156,"coverUrl":9,"views":157,"likes":30,"createdAt":158,"category":159,"tags":161,"author":9},83,"Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере","svoy-monitoring-uptime-kuma-ili-prometheus-s-grafana-i-pochemu-on-obyazan-jit-na-otdelnom-servere","Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере Вообще я микроразработчик, со мной можно связаться как угодн",93,"2026-08-09T05:54:48.670Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":160},{"id":20,"value":21,"content":22,"sortOrder":18},[162,163,164,168,169,170,171,172,176],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},{"id":165,"value":166,"content":167},113,"monitoring","Мониторинг",{"id":99,"value":100,"content":101},{"id":103,"value":104,"content":105},{"id":107,"value":108,"content":109},{"id":111,"value":112,"content":113},{"id":173,"value":174,"content":175},118,"nastroyka","Настройка",{"id":119,"value":120,"content":121},{"id":178,"title":179,"slug":180,"content":181,"description":181,"coverUrl":9,"views":182,"likes":30,"createdAt":183,"category":184,"tags":186,"author":9},82,"TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS)","tls-fingerprinting-kak-server-uznaet-tvoy-klient-ja3ja4-utls","TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS) Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой",66,"2026-08-07T21:34:46.778Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":185},{"id":20,"value":21,"content":22,"sortOrder":18},[187,188,189,190],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},{"id":103,"value":104,"content":105},{"id":119,"value":120,"content":121},{"id":192,"title":193,"slug":194,"content":195,"description":195,"coverUrl":9,"views":196,"likes":30,"createdAt":197,"category":198,"tags":200,"author":206},76,"Локальные LLM, что это, где брать и как запустить.","lokalnye-llm-chto-eto-gde-brat-i-kak-zapustit","Локальные LLM, что это, где брать и как запустить Локальные LLM — это те же самые языковые модели, но веса лежат у тебя на диске, а весь инференс крутится на тв",60,"2026-08-01T12:07:22.600Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":199},{"id":20,"value":21,"content":22,"sortOrder":18},[201,202,203,204,205],{"id":25,"value":26,"content":27},{"id":103,"value":104,"content":105},{"id":107,"value":108,"content":109},{"id":111,"value":112,"content":113},{"id":173,"value":174,"content":175},{"id":107,"name":207,"slug":9},"Lever",{"id":209,"title":210,"slug":211,"content":212,"description":212,"coverUrl":9,"views":213,"likes":30,"createdAt":214,"category":215,"tags":217,"author":9},74,"Xray core на пальцах: xmux, mux, fragment, noise и как это выглядит в трёх боевых конфигах.","xray-core","Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой проект: Zapret2UI. --- Если хоть раз тащили себе чужой конфиг для",81,"2026-07-31T04:59:26.141Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":216},{"id":20,"value":21,"content":22,"sortOrder":18},[218,219,220,221,222],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},{"id":103,"value":104,"content":105},{"id":107,"value":108,"content":109},{"id":173,"value":174,"content":175},{"id":224,"title":225,"slug":226,"content":227,"description":227,"coverUrl":9,"views":196,"likes":30,"createdAt":228,"category":229,"tags":231,"author":9},70,"FRP: Как играть с друзьями на домашнем сервере без белого IP и VPN","frp-kak-igrat-s-druzyami-na-domashnem-servere-bez-belogo-ip-i-vpn","FRP - как играть с друзьями без белого IP Ты поднял сервер Minecraft у себя дома, зовёшь друзей, а они не могут подключиться. Знакомая история? Разберёмся, поче","2026-07-30T14:29:58.703Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":230},{"id":20,"value":21,"content":22,"sortOrder":18},[232,233,234,235,236],{"id":25,"value":26,"content":27},{"id":103,"value":104,"content":105},{"id":107,"value":108,"content":109},{"id":111,"value":112,"content":113},{"id":119,"value":120,"content":121},{"id":238,"title":239,"slug":240,"content":241,"description":241,"coverUrl":9,"views":242,"likes":11,"createdAt":243,"category":244,"tags":246,"author":9},59,"Выбор Хостинга. Как хостеры оверселят VPS — и как проверить, что вам реально дали ресурсы","vybor-hostinga-kak-hostery-overselyat-vps--i-kak-proverit-chto-vam-realno-dali-resursy","Как хостеры оверселят VPS — и как проверить, что вам реально дали ресурсы Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторо",90,"2026-07-13T14:02:13.757Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":245},{"id":20,"value":21,"content":22,"sortOrder":18},[247],{"id":25,"value":26,"content":27},{"id":4,"title":5,"slug":6,"content":8,"description":8,"coverUrl":9,"views":10,"likes":11,"createdAt":12,"category":249,"tags":251,"author":9},{"id":15,"value":16,"content":17,"sortOrder":18,"parent":250},{"id":20,"value":21,"content":22,"sortOrder":18},[252],{"id":25,"value":26,"content":27},["Island",254],{"key":255,"result":256},"ArticleBody_0pOP0fxvvV4anUB6eySJpr3peXgFfehyyI5uqZqEI",{"head":257},{},1788480096182]