Базовая настройка обратного прокси требует всего трёх решений, и это руководство поможет с каждым: имя хоста, путь и бэкенд. Понятие «HTTP-прокси» может означать как прямой, так и обратный прокси, но здесь вы планируете и проверяете сервер, который запускаете самостоятельно. Агент никогда не решает за вас, какой хост или путь выбрать. Он записывает то, что вы просите, показывает каждое изменение как diff и отчитывается о реальном результате каждой команды, чтобы вы могли увидеть эффект каждого решения перед следующим. Пройдите четыре шага ниже по порядку и рассматривайте план маршрутизации как документ, которому вы и агент следуете от первой команды до последнего запроса.
Запустите Segment Route и откройте рабочую папку, содержащую файлы конфигурации и маршрутов. Инструменты работы с файлами работают в этой папке, поэтому чистая папка, содержащая только файлы, имеющие отношение к этому домену, делает диффы короткими, а результаты поиска — читаемыми. Если ваши файлы в рабочей среде находятся на сервере, которым вы владеете, сначала скопируйте их в папку или выберите среду SSH для команд и храните план в папке.
Попросите агента создать файл routing-plan.txt с вашими маршрутами, перенаправлениями и ожидаемыми кодами состояния для каждого. План — это обычный текст, который можно редактировать; в конце вы будете сравнивать с ним реальные результаты. Укажите одно ожидание для каждого маршрута и каждого перенаправления, чтобы ни одно правило не осталось без проверки. Держите файл коротким и читаемым.
Подтвердите diff для каждого правила, затем позвольте Shell запустить команду тестирования конфигурации перед любой перезагрузкой. В режиме Ask first агент приостанавливается перед каждым изменением, а карточка теста показывает реальный код выхода и полный вывод. Никогда не перезагружайте, пока тест не пройден, и сохраняйте резервную копию предыдущего файла до подтверждения нового поведения.
Отправьте запрос к каждому адресу, прочитайте код состояния и заголовок Location и сравните их с вашим планом. Если одно значение отличается, восстановите резервную копию, перезагрузите и измените одно правило снова. Повторяйте, пока каждое ожидание в плане не совпадёт с результатом, затем сохраните финальный план как запись того, что должна делать конфигурация.
.3 файлаroutes.confзагруженоrouting-plan.txtсохраненоyour request commandзаписано# routing plan for my own domain
# one line per rule, written before any change
route 1: host app, path /api, goes to service api
route 2: host app, path /, goes to service web
route 3: host admin, path /, goes to service admin
redirect 1: old page to new page, code 301
redirect 2: www host to bare host, code 301
redirect 3: http to https, code 301
# status to expect after the change
expect 1: app path /api answers with a success code
expect 2: old page answers 301 and gives the new address
# keep the old configuration file as a backup
# end of routing planКаждая строка — это одно правило или одно ожидание. Написанный первым, план даёт вам то, с чем можно сравнить реальные коды состояния после каждого изменения, и изменение, которое нарушает ожидание, легко обнаружить. Хосты, пути и сервисы — это только примеры; замените их своими и храните план рядом с конфигурацией, которую он описывает. Слова redirect с кодом достаточно агенту, чтобы знать, что писать.
Это руководство по самостоятельному хостингу с обратным прокси-сервером перед вашими сервисами начинается с поиска того, где хранятся правила. list_dir показывает рабочую папку, glob перечисляет файлы, похожие на списки маршрутов, а grep ищет в них слова route и redirect. Результат — короткий список с именами файлов и номерами строк. Пока ничего не меняется. Выберите файл, содержащий правила для вашего домена, откройте его с помощью read_file и запросите каждый адрес, чтобы записать текущий код состояния. Просмотрите список в режиме Plan only, если хотите, чтобы агент сначала предложил порядок работы, и сохраните заметки рядом с вашим планом маршрутизации, чтобы первые коды состояния были зафиксированы.
Изменяйте одно правило за раз, потому что небольшой diff легко оценить. edit_file читает файл, предлагает новую строку и показывает diff с добавленными и удалёнными строками. Когда возникает вопрос о правиле перенаправления поддомена, агент показывает правило рядом с кодом, который оно должно вернуть, и вы принимаете решение. В режиме Ask first ничего не сохраняется, пока вы не примете. Auto-run сохранит сразу, поэтому используйте его только для файлов, которые можно восстановить. Сохраните старый файл как резервную копию, примите diff и переходите к следующему шагу. Отклоните diff, если одна строка удивит вас, и попросите меньшее изменение.
Перезагрузка с ошибочным файлом может вывести из строя рабочий сайт, поэтому сначала протестируйте. Shell запускает вашу команду тестирования конфигурации, и успех оценивается по реальному коду выхода: успешный код означает, что файл был разобран, любой другой означает, что вы остаётесь на старой конфигурации. Карточка раскрывается до полного вывода, включая номер строки ошибки. Исправьте её с помощью другого небольшого diff. После прохождения теста перезагрузите, снова запросите адрес и сравните коды состояния HTTP старого и нового запусков. Просмотрите вывод самостоятельно, поскольку успешный тест говорит только о том, что синтаксис верен, а не о том, что маршрут настроен правильно.
Коды состояния группируются по первой цифре: 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера. Для прокси 502 означает недействительный ответ от бэкенда, 503 означает недоступность сервиса, 504 означает, что бэкенд ответил слишком медленно, а 404 означает не найдено. http_get загружает одну страницу вашего сервиса, а команда запроса показывает новый адрес перенаправления. Если код отличается от вашего плана, восстановите файл резервной копии, перезагрузите и протестируйте снова. Затем измените план или правило и повторите, одно правило за раунд. Короткий план маршрутизации и файл резервной копии — это всё, что нужно для отката.
