Админы, вам пора менять профессию. Claude Code настраивает серверы лучше вас

в понимании того что происходит "под капотом" nginx
Узнайте у своего агента результат, если он справится с этим тривиальным 10-строчником, то можно будет начать ему доверять :)

Хехе.. Ну впирьод ))

Ключевое: "Понимаю в принципе как, но лень было".
Я сама вижу, какую дичь Claude иногда выдает и прошу сделать по-другому. Потому что я знаю, как. А человек без знаний не задумается и съест. Разницу понимаете? И, конечно, у меня нет никаких агентов, которые имеют доступ к моим логинам/паролям/явкам. Я логинюсь через SSH key и в консоль руками копирую.  Ума еще хватает не давать агентам свои входы.

ну и если тот десятистрочник окажется для него неподъёмным дайте совсем детскую задачку

server {
  listen       *:80;
  server_name  .example.com;
  
  location / {
    rewrite ^ /one;
    return 200 "zero\n";
  }
 
  location /one {
    return 200 "one\n";
  }
}

$ GET -S example.com

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

server {
    listen       *:80;
    server_name  .example.com;

    add_header "Content-Type" "text/html; charset=UTF-8" always;

    location /bu {
        return 200 'bu!\n';
    }
}

Попросите его сделать ограничение количества запросов от одного IP-адреса к локейшину /bu
Куда уж проще задача...

Ну давай попробуем. Что ответил ГПТ -

Последовательность выполнения
1. Обработка запроса /

При запросе:

GET -S example.com

выполняются инструкции:

set $test one;
$test = "one"
Далее
echo "root: $test";

Вывод:

root: one
Следующая строка
set $test "$test two";

Теперь:

$test = "one two"
Затем
auth_request /auth;

Создаётся subrequest к /auth.

2. Выполнение /auth

В subrequest переменные наследуются.

Поэтому $test изначально:

one two
Выполняется
set $test "$test auth_pre";
$test = "one two auth_pre"
Затем
return 200 "auth: $test\n";

Subrequest возвращает:

auth: one two auth_pre

Но важно:

auth_request использует только HTTP статус, тело ответа игнорируется.

Эта строка никогда не выполнится
set $test "$test auth_post";

Потому что return завершает обработку.

3. Возврат в основной запрос

После auth_request выполнение продолжается:

set $test "$test three";

Теперь:

$test = "one two three"

Но этот результат уже нигде не выводится.

Итоговый ответ клиенту

Ответ:

HTTP/1.1 200 OK

root: one

Почему:

echo выполняется до auth_request

тело subrequest игнорируется

других echo нет

Проблемы конфигурации
1. echo — нестандартный модуль
echo "root: $test";

Работает только при установленном модуле:

ngx_http_echo_module

В стандартной сборке NGINX его нет.

2. /auth доступен извне

Сейчас любой пользователь может вызвать:

/auth

Это потенциальная уязвимость.

3. Мёртвый код
return 200 "auth: $test\n";
set $test "$test auth_post";

Код после return никогда не выполняется.

4. Переменные в subrequest

Переменные могут вести себя неожиданно при использовании:

auth_request

Поскольку subrequest наследует контекст.

Оптимизированная версия
server {
  listen 80;
  server_name example.com;

  location / {

    set $test "one";

    echo "root: $test";

    set $test "$test two";

    auth_request /auth;

    set $test "$test three";
  }

  location = /auth {
    internal;

    set $test "$test auth_pre";

    return 200;
  }
}
Что исправлено
1. Закрыт доступ к /auth
internal;

Теперь этот location может вызываться только из NGINX.

2. Убрано тело ответа
return 200;

Потому что auth_request тело не использует.

3. Удалён мёртвый код

Удалено:

set $test "$test auth_post";
Правильная передача данных из auth_request

Если нужно вернуть данные из авторизации, используется:

auth_request_set

Пример:

location / {

  auth_request /auth;

  auth_request_set $user $upstream_http_x_user;

  echo "user=$user";
}

location = /auth {

  internal;

  add_header X-User admin;

  return 200;
}

Ответ:

user=admin
Вывод

При выполнении:

GET -S example.com

ответ будет:

HTTP/1.1 200 OK

root: one

Причины:

echo выполняется до auth_request

тело subrequest игнорируется

return завершает обработку /auth

Ответ cloude

Анализ Nginx-конфигурации
Что произойдет при GET -S example.com
Ответ клиенту будет: root: one two three

Корневая проблема: фазы обработки Nginx
Nginx обрабатывает директивы не в порядке их записи в конфиге, а по фазам:

Фаза    Директивы       Порядок
REWRITE_PHASE   set     1-я
ACCESS_PHASE    auth_request    2-я
CONTENT_PHASE   echo    3-я
Реальный порядок выполнения в location /:

Разработчик, видимо, ожидал, что echo выведет "root: one" — это не так.

Ошибка 1: мёртвый код в /auth
return немедленно завершает обработку запроса. Строка после него — мёртвый код.

Ошибка 2: изоляция переменных в подзапросе
auth_request создаёт внутренний подзапрос с собственным scope переменных. $test в /auth не наследует значение из родительского / — она начинается как пустая строка.

Тело ответа /auth (auth: auth_pre\n) клиенту не отправляется — auth_request использует только HTTP-статус (2xx = разрешить, 401/403 = запретить).

Ошибка 3: нестандартный модуль echo
Директива echo — это не стандартный Nginx, а ngx_http_echo_module от OpenResty. В дистрибутивном Nginx этого модуля нет, конфиг упадёт с ошибкой.

Исправленная и оптимизированная версия
Если нужно отлаживать значения переменных на разных этапах — используйте error_log через lua_log (OpenResty) или add_header:

Итог ошибок
#       Проблема        Эффект
1       Смешение фаз set/echo/auth_request      echo видит финальное значение $test, а не промежуточное
2       Код после return в /auth        Мёртвый код, никогда не выполняется
3       Ожидание наследования $test в подзапросе        Переменная в /auth всегда пустая (независимый scope)
4       Использование echo      Не стандартный Nginx, требует сторонний модуль

GPT

http {

    limit_req_zone $binary_remote_addr zone=bu_limit:10m rate=5r/s;

    server {
        listen *:80;
        server_name .example.com;

        add_header "Content-Type" "text/html; charset=UTF-8" always;

        location /bu {

            limit_req zone=bu_limit burst=10 nodelay;

            return 200 "bu!\n";
        }
    }
}

Что скажешь?

Ч.Т.Д.
Модели "обучились" на типичных ошибках/непонимании работы nginx и уверенно их воспроизводят, хотя cloude даже "нашёл" верный путь (порядок фаз), но "не смог" по нему пройти :)
Если, что правильный ответ

$ GET -S example.com
GET http://example.com
200 OK
root: one two three auth_pre

происходит это, потому что сначала выполнятся ВСЕ set, потом апосле них выполнится директива auth_request и только потом в фазе NGX_HTTP_CONTENT_PHASE будет отдан контент

именно та ошибка, которая и ожидалась
директива return ВСЕГДА будет выполняться до limit_req, потому что return в фазе NGX_HTTP_REWRITE_PHASE исполнится раньше чем дойдёт ход до NGX_HTTP_PREACCESS_PHASE.
limit_req здесь не будет исполняться НИКОГДА

чтобы это решить нужно return вынести в именованный локейшин