Как проверить работоспособность профиля маршрутизации в Stash: комплексная валидация

Профиль маршрутизации в Stash проверяют по нескольким уровням: сопоставляют правила с ожидаемым поведением, изучают таблицы маршрутизации IPv4 и IPv6, проверяют DNS, активные соединения, фактический путь пакетов, TCP- и UDP-сценарии, качество сети и журналы. Такая последовательность показывает, куда профиль должен направить трафик и куда он действительно его направил.

Открытие одного сайта не подтверждает исправность всей конфигурации. Другое доменное правило может иметь ошибочный приоритет, IPv6 может обходить туннель, DNS может вернуть неожиданный адрес, а приложение может сохранить старую сессию после изменения профиля. Итог проверки должен выглядеть как матрица тестов со статусами PASS или FAIL, а не как единичный успешный запрос.

Stash умеет маршрутизировать соединения по домену, IP-CIDR, GEOIP, GEOSITE и имени процесса. Профиль можно проверять отдельно для приложений, прокси-серверов, прямого подключения, TCP, UDP, IPv4 и IPv6. Ниже приведена процедура, которую удобно использовать перед публикацией изменений в рабочей среде.

Как проверить работоспособность профиля маршрутизации: краткий алгоритм

Проверку выполняйте в фиксированном порядке. Сначала подтвердите логику конфигурации, затем проверьте системные маршруты и только после этого анализируйте реальные сессии.

Из каких уровней состоит комплексная проверка

1. Конфигурация. Зафиксируйте версию Stash, исходный профиль, активные правила, переопределения и формат файла. Stash может читать конфигурации, совместимые с Clash.
2. Правила. Проверьте условия по домену, IP-CIDR, GEOIP, GEOSITE и имени процесса. Отдельно изучите порядок правил, исключения и финальное действие.
3. Таблицы ядра. Сопоставьте ожидаемый путь с таблицами IPv4 и IPv6, маршрутами по умолчанию, шлюзами, интерфейсами и метриками.
4. DNS. Проверьте кэш, новые DNS-запросы, выбранный резолвер, DoH и DoQ. Сопоставьте полученные A- и AAAA-записи с правилами.
5. Активные соединения. Убедитесь, что конкретная сессия использует ожидаемый прокси-сервер, группу или прямой маршрут.
6. Путь пакетов. Сравните прямой маршрут и маршрут через прокси с помощью traceroute, tracert или mtr. Для локального участка применяйте tcpdump или Wireshark.
7. Функциональные тесты. Проверьте TCP, UDP, разные приложения, домены, IP-диапазоны, IPv6 и потоковое мультимедиа.
8. Качество. Измерьте задержку, потери, стабильность и пропускную способность. Один успешный ответ не показывает качество канала под нагрузкой.
9. Журналы и приёмка. Свяжите каждый тест с записью журнала, зафиксируйте доказательства и примите решение о публикации либо откате профиля.

Почему доступность одного ресурса не доказывает корректность профиля

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

• Домен открывается по IPv4 через туннель, но AAAA-запись уводит IPv6-трафик напрямую.
• TCP-соединение к веб-сервису устанавливается, а UDP-сервис теряет пакеты или не поддерживается выбранным прокси.
• Тестовый домен проходит через прокси, но приложение обновлений совпадает с правилом-исключением.
• Доменное правило выглядит корректным, однако его перекрывает более раннее общее правило.
• DNS возвращает адрес CDN, который попадает под другое IP-CIDR или GEOIP-условие.
• Приложение продолжает использовать сессию, созданную до изменения профиля.

Поэтому проверяйте минимум один положительный и один отрицательный сценарий для каждого типа правила. Для критичных сервисов добавьте отдельные проверки TCP, UDP, IPv4, IPv6 и приложений.

Подготовьте эталон маршрутизации до начала тестов

До запуска трафика опишите ожидаемое поведение профиля. Запись «сайт должен работать» слишком общая. Нужны конкретные признаки: какой процесс выполняет запрос, какой адрес назначения используется, через какой узел проходит сессия и какой результат считается приемлемым.

Составьте матрицу тестовых сценариев

Матрица помогает проверить исключения и не повторять один и тот же тест из одного приложения. В неё включите положительные, отрицательные и пограничные случаи.

Зафиксируйте версию и фактическую активную конфигурацию

Сохраните точную версию Stash, дату проверки, имя профиля и источник конфигурации. Отдельно запишите, загружен ли файл, совместимый с Clash, или правила менялись через визуальный редактор.

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

• исходный файл профиля;
• активную конфигурацию Stash;
• переопределения модулей;
• список прокси и групп;
• время последней загрузки и применения изменений.

Если тестируете обновлённую конфигурацию, сохраните предыдущую рабочую копию. Это позволит быстро вернуть старые правила при обнаружении ошибки.

Для изолированного стенда можно использовать отдельный VDS или VPS, чтобы не менять рабочий клиент во время проверки. Облачная инфраструктура Timeweb Cloud подходит для временного тестового окружения с сервером и сетевыми ресурсами.

Опишите ожидаемый маршрут для каждого кейса

Для каждой строки матрицы укажите четыре группы признаков:

• Условие: домен, IP-CIDR, GEOIP, GEOSITE или имя процесса.
• Направление: конкретный прокси, группа прокси, туннель или DIRECT.
• Сетевой контекст: DNS-резолвер, IPv4 или IPv6, TCP или UDP.
• Доказательство: запись активного соединения, журнал, результат трассировки или снимок сетевого анализатора.

Пример критерия: «браузер обращается к test.example по TCP/443, DNS-запрос уходит через выбранный резолвер, сессия проходит через группу proxy-eu, задержка не превышает 180 мс, в журнале нет повторных подключений». Такое описание позволяет коллеге повторить тест без устных пояснений.

Проверка правил маршрутизации: порядок, условия и исключения

Сначала анализируйте логику профиля. Если правило не совпадает с фактическими данными соединения или перекрывается более ранним условием, проверка таблицы маршрутов не найдёт корень проблемы.

Проверьте типы условий: домен, IP-CIDR, GEOIP и GEOSITE

Разные условия анализируют разные признаки трафика:

• Доменное правило сопоставляет имя, к которому обращается приложение.
• IP-CIDR работает с адресом назначения и маской сети. Например, правило для 10.20.0.0/16 охватывает адреса внутри этой подсети, но не соседнюю сеть 10.21.0.0/16.
• GEOIP выбирает действие по географической принадлежности IP-адреса. Результат зависит от актуальности базы и конкретного адреса CDN.
• GEOSITE сопоставляет домен с тематическим или региональным набором. Один домен может иметь несколько записей и связанных поддоменов.
• Имя процесса связывает политику с приложением. Два приложения могут обращаться к одному домену и получать разный маршрут.

Для доменного правила зафиксируйте имя, которое видит Stash, и IP-адреса, полученные через DNS. Для IP-CIDR проверьте маску, диапазон и семейство адресов. Для GEOIP и GEOSITE подтвердите актуальность наборов и проверьте несколько адресов или поддоменов.

Проверьте приоритет правил и финальное правило

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

1. Найдите общее правило, которое может совпасть раньше специального.
2. Проверьте исключения для доменов, подсетей и процессов.
3. Сравните порядок правил для IPv4 и IPv6.
4. Определите действие для трафика без совпадения.
5. Проверьте, что финальное правило не отправляет неизвестные соединения в обход политики.

Особенно внимательно изучите широкие доменные маски, крупные IP-CIDR, правила для регионов и универсальные действия вроде DIRECT или REJECT. После каждого изменения тестируйте ресурс, который должен совпасть с новым правилом, и ресурс, который обязан остаться на прежнем маршруте.

Проверьте маршрутизацию по приложениям и переопределения

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

Откройте приложение, указанное в правиле, создайте новую сессию и найдите её в списке соединений Stash. Затем повторите запрос из приложения-исключения. Сравните процесс, адрес назначения, прокси-группу и протокол.

После изменения через визуальный редактор проверьте итоговую активную конфигурацию. Если применялось переопределение модуля, временно отключите его и повторите тест. Разница между результатами покажет, какой слой изменяет маршрут.

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

Как проверить таблицу маршрутизации IPv4 и IPv6

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

Проверьте таблицу маршрутизации IPv4

На Linux используйте:

ip -4 route show
ip -4 rule show
ip -4 route get 203.0.113.10

На macOS полезны команды:

netstat -rn -f inet
route -n get 203.0.113.10

На Windows выполните:

route print -4

Проверьте для каждого тестового IP:

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

Команда ip route get полезнее простого просмотра списка: она показывает, какой маршрут ядро выберет для конкретного адреса. Проверяйте адрес прокси-узла и адрес целевого ресурса отдельно.

Проверьте таблицу маршрутизации IPv6 отдельно

IPv6 нельзя считать автоматически проверенным после успешного IPv4-теста. На Linux:

ip -6 route show
ip -6 rule show
ip -6 route get 2001:db8::10

На macOS:

netstat -rn -f inet6
route -n get -inet6 2001:db8::10

На Windows:

route print -6

Выберите для IPv6 одно явное ожидаемое состояние:

• IPv6 проходит через туннель;
• IPv6 подключается напрямую через указанный интерфейс;
• IPv6 отключён, а приложения используют IPv4;
• IPv6 доступен только для определённых сетей.

Ошибка возникает, когда профиль рассчитан на проксирование, а система сохраняет рабочий IPv6-маршрут по умолчанию в обход туннеля. Зафиксируйте интерфейс, шлюз и метрику IPv6 отдельно от IPv4.

Найдите конфликтующие маршруты и неверные метрики

Ищите более специфичные записи, которые перехватывают трафик раньше общего маршрута. Например, маршрут к подсети 192.0.2.0/24 будет выбран вместо маршрута по умолчанию, даже если его интерфейс временно не обслуживает нужный сервис.

Проверьте следующие признаки:

• две записи для одной сети с разными шлюзами;
• маршрут через отключённый или несуществующий интерфейс;
• неожиданный маршрут по умолчанию;
• метрика, из-за которой выбирается резервный путь;
• локальная сеть, пересекающаяся с сетью за прокси или VPN;
• разные решения ядра для адресов A и AAAA.

Если причина связана с black hole, MTU или асимметричным путём, используйте руководство по диагностике сетевой маршрутизации с traceroute, mtr и ip route.

Проверка DNS: имя должно разрешаться в правильном контексте

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

Проверьте DNS-кэш и новые DNS-запросы

В Stash изучите DNS-кэш и список новых запросов. Для каждого тестового домена зафиксируйте время получения записи, A- и AAAA-адреса, используемый резолвер и момент создания соединения.

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

Сопоставьте DNS-результат с активной сессией. Адрес в кэше и адрес назначения в списке соединений должны соответствовать одному тесту. При нескольких A- или AAAA-записях повторите проверку несколько раз: CDN может выбирать разные узлы.

Проверьте DNS через HTTPS и DNS через QUIC

Stash поддерживает встроенный DNS-сервер, DNS over HTTPS и DNS over QUIC. Проверьте:

• какой DNS-сервер выбран для профиля;
• доступен ли канал DoH или DoQ;
• через какой интерфейс уходит DNS-запрос;
• не дублируются ли запросы через системный резолвер;
• совпадает ли маршрут DNS с требованиями политики.

При проверке DNS-утечек анализируйте сам запрос, интерфейс выхода и момент его выполнения. Практические проверки DNS, HTTPS-сертификатов и внешнего IP собраны в руководстве по безопасности прокси-сервера.

Сопоставьте DNS-результат с доменными и IP-правилами

Домен может совпасть с доменным правилом, а полученный IP-адрес одновременно попасть под IP-CIDR или GEOIP. Проверьте, какое условие имеет больший приоритет и какое действие Stash применяет первым.

Отдельно сравните IPv4 и IPv6:

1. получите A- и AAAA-записи;
2. создайте TCP-сессию по IPv4;
3. создайте TCP-сессию по IPv6, если ресурс его поддерживает;
4. сравните выбранный маршрут и прокси-узел;
5. проверьте, не меняется ли результат при повторном DNS-запросе.

Если домен использует CDN, один тестовый адрес не описывает все варианты. Добавьте несколько повторов и зафиксируйте каждый фактически использованный IP.

Проверка маршрутизации трафика по активным соединениям

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

Проверьте, через какой узел проходит сессия

Для каждого теста найдите в списке:

• имя приложения или процесса;
• домен и IP-адрес назначения;
• тип соединения, TCP или UDP;
• выбранную политику;
• прокси-сервер или группу прокси;
• статус, время создания и длительность сессии.

Сравните эти данные с матрицей. Если ожидался прокси-узел, в активной сессии должна быть видна соответствующая конечная точка. Для DIRECT проверьте интерфейс и отсутствие неожиданного туннельного соединения.

Запись в таблице маршрутизации показывает доступный системный путь. Активное соединение показывает, как конкретный трафик проходит через профиль. Для приёмки нужны оба подтверждения.

Проверьте маршрутизацию на уровне отдельных приложений

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

Пример проверки:

1. Запустите браузер и откройте домен, который должен идти через туннель.
2. Найдите сессию браузера в Stash и запишите прокси-узел.
3. Выполните запрос к тому же домену из терминала.
4. Сравните процесс, DNS-запрос, IP-адрес и выбранное правило.
5. Повторите действия из приложения-исключения.

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

Повторите проверку после изменения профиля

После изменения правил завершите старые тестовые соединения. Stash позволяет закрыть сессию из списка активных подключений. Создайте новые соединения и отметьте время их появления.

При необходимости очистите DNS-кэш и перезапустите приложение. Старую сессию нельзя использовать как доказательство того, что новая политика уже действует.

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

Трассировка маршрута до узла и анализ прохождения пакетов

Трассировка помогает увидеть промежуточные узлы и задержки, но её результат нужно правильно интерпретировать. Для проксируемого трафика локальная команда часто показывает путь до прокси-сервера, а не полный путь до конечного ресурса.

Сравните прямой маршрут и маршрут через прокси

Проведите два сопоставимых теста: один через DIRECT, второй через выбранную прокси-группу. Зафиксируйте первый доступный шлюз, наблюдаемый конечный узел, задержку и потери.

На Linux можно использовать:

traceroute -4 TARGET_HOST
traceroute -T -p 443 TARGET_HOST
mtr -rwzbc 20 TARGET_HOST

На Windows:

tracert -4 TARGET_HOST
pathping TARGET_HOST

Если Stash устанавливает туннель, трассировка с хоста обычно подтверждает путь до прокси-узла. Маршрут после выхода из прокси нужно оценивать по активной сессии, журналам, внешнему наблюдателю или результату приложения. Не делайте вывод о полном пути до сервера по одному локальному traceroute.

Используйте трассировку с учётом протокола

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

• Для веб-сервиса проверяйте TCP к порту 443.
• Для UDP-приложения используйте UDP-режим, если его поддерживает установленная утилита.
• Для постоянного наблюдения применяйте mtr с несколькими десятками циклов.
• Сравнивайте среднюю задержку, максимальную задержку и процент потерь.

Тест должен соответствовать реальному сервису. ICMP-пинг полезен для проверки базовой связности, но не подтверждает установление TLS, работу конкретного TCP-порта или прохождение UDP через прокси.

Проверьте пакеты на локальном интерфейсе

tcpdump и Wireshark позволяют увидеть, какой трафик покидает хост, через какой интерфейс он уходит и не возникает ли прямого соединения в обход туннеля.

Пример фильтра tcpdump для контрольного IPv4-адреса:

sudo tcpdump -ni any host 203.0.113.10

Для проверки DNS и TCP-порта можно сузить фильтр:

sudo tcpdump -ni any 'port 53 or port 443'
sudo tcpdump -ni any 'host 203.0.113.10 and tcp'

В Wireshark фильтруйте адрес назначения, порт и интерфейс. Сравните:

• уходит ли DNS через ожидаемый интерфейс;
• есть ли прямое TCP-соединение к целевому IP;
• виден ли трафик до прокси-сервера;
• какой интерфейс используется при IPv4 и IPv6;
• появляется ли повторное соединение после ошибки туннеля.

Шифрование и туннелирование скрывают содержимое и часть пути. Анализатор покажет локальный участок и факт соединения, но не расшифрует маршрут после выхода из прокси без доступа к соответствующему узлу.

Проверка TCP, UDP и сценариев приложений

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

Проверьте TCP-сценарии

Для TCP-проверки выберите веб-сервис, API, репозиторий или другой рабочий ресурс. Проверьте установление соединения, TLS, передачу данных, повторные подключения и завершение сессии.

curl -I https://TARGET_HOST
nc -vz TARGET_HOST 443

Команда curl показывает результат прикладного запроса, а nc проверяет доступность TCP-порта. Они не заменяют анализ активного соединения Stash: после выполнения команд найдите процесс и прокси-узел в списке сессий.

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

Проверьте UDP-сценарии

UDP нужно тестировать приложением, которое действительно использует этот протокол. Подойдут DNS, голосовой сервис, потоковая передача или специализированный клиент. Поведение утилит для UDP зависит от операционной системы, поэтому результат команды сверяйте с активной сессией и журналом.

Проверьте:

• создаётся ли UDP-сессия;
• выбран ли ожидаемый прокси или прямой маршрут;
• есть ли потери и резкие скачки задержки;
• не переходит ли приложение незаметно на TCP;
• поддерживает ли выбранный прокси нужный тип UDP-трафика.

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

Проверьте правила для конкретных приложений

Запустите приложение, включённое в правило, и создайте новую сессию. Затем повторите тот же сценарий из приложения-исключения. Сравните активные соединения, DNS-запросы, протокол и выбранную конечную точку.

Проверяйте приложение в нескольких режимах: запуск с чистым кэшем, повторное подключение после смены сети, обращение к IPv4-ресурсу и обращение к IPv6-ресурсу. Такой набор выявляет сохранённые сессии и различия сетевых стеков.

Проверьте доступность потокового мультимедиа

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

В Stash используйте отдельную проверку доступности потокового мультимедиа, если она доступна в вашей версии клиента. Во время теста наблюдайте за активными соединениями и журналами. Зафиксируйте:

• время начала воспроизведения;
• появление новых CDN-доменов;
• выбранные прокси-узлы;
• переходы между TCP и UDP;
• буферизацию, обрывы и изменение качества.

Проверка доступности, скорости и качества соединения

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

Проверьте доступность контрольных ресурсов

Выберите контрольные ресурсы из разных категорий:

• домен с маршрутом через прокси;
• домен с прямым подключением;
• IP-адрес из проверяемого CIDR;
• ресурс, который должен совпасть с GEOIP или GEOSITE;
• приложение через туннель;
• приложение-исключение;
• IPv6-ресурс;
• потоковый сервис.

Для каждого результата запишите не только факт доступности, но и маршрут, IP-адрес, протокол, процесс и время проверки.

Измерьте задержку, потери и пропускную способность

В Stash используйте встроенные тесты скорости и качества сети. Для сравнения запускайте одинаковое число измерений через DIRECT и разные прокси-группы. Три-пять повторов дают более полезную картину, чем один запуск.

Зафиксируйте среднюю и максимальную задержку, потери пакетов, пропускную способность, стабильность и джиттер, если инструмент его показывает. Сравнивайте результаты для одного ресурса, одного времени и одного типа протокола.

Пороги в таблице служат примером. Для продакшена задайте значения по SLA конкретного сервиса и внутренним требованиям команды.

Определите приемлемые пороги для рабочей среды

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

Если показатели не проходят порог, проверьте другой прокси-узел, маршрут DNS и MTU. Меняйте одно условие за раз и заново запускайте ту же серию измерений. Иначе невозможно определить, какое изменение повлияло на результат.

Журналы и системная информация: поиск скрытых ошибок

Журналы выполнения Stash и системная информация раскрывают ошибки, которые маскируются успешным подключением. Ищите сбои применения правил, ошибки DNS, тайм-ауты прокси, обрывы туннеля, повторные попытки и неожиданный прямой выход.

Свяжите запись журнала с конкретным тестом

Перед каждым тестом запишите точное время, приложение и сценарий. После запроса найдите в журнале события в том же временном интервале:

1. получение DNS-ответа;
2. выбор правила;
3. создание соединения;
4. подключение к прокси-узлу;
5. установление TCP или UDP-сессии;
6. ошибка, повторная попытка или завершение соединения.

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

Разберите типовые расхождения между правилом и трафиком

Если активная сессия использует неправильный маршрут, проверяйте причины в следующем порядке:

1. активна ли нужная версия профиля;
2. не изменили ли результат визуальный редактор или модульное переопределение;
3. какое правило совпало первым;
4. какой IP вернул DNS;
5. какой стек, IPv4 или IPv6, использует приложение;
6. совпадает ли имя процесса с правилом;
7. не осталось ли старое соединение;
8. доступен ли выбранный прокси;
9. что записал журнал в момент создания сессии.

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

Проверьте системную информацию после изменения профиля

Сохраните состояние интерфейсов, адресов IPv4 и IPv6, туннеля, прокси-узла и системных ошибок до и после изменения. Сравнение показывает, не изменился ли шлюз, не исчез ли маршрут и не появился ли новый интерфейс.

Проверьте:

• состояние сетевых интерфейсов;
• локальные адреса и маски;
• маршруты по умолчанию;
• состояние туннеля;
• доступность прокси-группы;
• системные сообщения о DNS, сокетах и тайм-аутах.

Если проблема связана с подключением к сервису аутентификации, отделите маршрутизацию от DNS, VPN, proxy и TLS. Для такой последовательности полезна шпаргалка по диагностике сети, DNS и TLS.

Финальная валидация профиля перед продакшен-развертыванием

Финальная проверка должна оставлять набор доказательств, который можно передать коллеге, приложить к заявке на изменение и использовать при откате. Каждый критичный сценарий получает ожидаемый результат, фактический результат, подтверждение и статус.

Чек-лист обязательных проверок

• Записана версия Stash и дата проверки.
• Сохранены исходный профиль и активная конфигурация.
• Проверен формат Clash, если профиль загружен в таком виде.
• Проверены визуальные изменения и переопределения модулей.
• Проверены порядок правил, исключения и финальное действие.
• Проверены доменные, IP-CIDR, GEOIP, GEOSITE-условия и имена процессов.
• Проверены таблицы маршрутизации IPv4 и IPv6.
• Проверены шлюзы, интерфейсы, маршруты по умолчанию и метрики.
• Проверены DNS-кэш, новые запросы, DoH и DoQ.
• Проверены новые активные соединения после изменения профиля.
• Проверены TCP, UDP, приложения и потоковое мультимедиа.
• Проведена трассировка до прокси-узла и локальный анализ пакетов.
• Измерены задержка, потери, пропускная способность и стабильность.
• Сохранены журналы выполнения и системная информация.
• Подготовлен план возврата предыдущего профиля.

Критерии PASS/FAIL для каждого сценария

Статус PASS ставьте при совпадении всех критичных признаков. Успешный HTTP-ответ без подтверждения маршрута получает статус UNKNOWN, а не PASS.

Частичный результат отмечайте отдельно. Например, TCP через прокси получил PASS, UDP через тот же узел получил FAIL, а IPv6 не тестировался и получает UNKNOWN. Такой формат лучше отражает фактический риск.

Зафиксируйте результаты и план отката

Сохраните комплект артефактов:

• версию профиля и список изменений;
• снимок активной конфигурации;
• матрицу тестов со статусами;
• вывод таблиц IPv4 и IPv6;
• данные DNS-кэша и запросов;
• список активных соединений;
• результаты traceroute, mtr, tcpdump или Wireshark;
• измерения качества сети;
• журналы выполнения и системную информацию.

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

Когда профиль можно считать готовым к продакшену

Профиль готов к публикации, если все критичные строки матрицы получили PASS. Для каждого сценария подтверждены правило, фактическая конечная точка, DNS, протокол и качество. IPv4 и IPv6 проверены отдельно, а старые сессии исключены из результатов.

Публикацию отложите, если есть необъяснимый IPv6-обход, DNS-утечка, различие между активной и исходной конфигурацией, нестабильный UDP, превышение порогов качества или отсутствие плана отката. Сначала локализуйте причину, затем изменяйте одно правило и повторяйте полный набор затронутых тестов.

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