# конспект · шаг 5 из 5
Конспект: код и причина
Код ответа говорит категорию, error_log - причину. Разбор всегда идёт
по второй.
Первый вопрос к любой строке
Есть ли в ней адрес в $upstream_addr? Прочерк - решение принял nginx, разбираться
надо в его конфиге. Адрес - запрос дошёл до бэкенда, и код мог прийти оттуда.
4xx
| Код | Строка в логе | Причина |
|---|---|---|
| 404 | open() "…" failed (2: No such file…) |
путь в кавычках - то, что nginx реально искал |
| 403 | open() "…" failed (13: Permission denied) |
воркеру не хватает прав на файл или каталог пути |
| 403 | directory index of "…" is forbidden |
запрос на каталог, нет index |
| 403 | access forbidden by rule |
сработал deny |
| 413 | client intended to send too large body |
client_max_body_size, по умолчанию 1 МБ |
| 100 | - | ответ на Expect: 100-continue; при превышении лимита вместо него сразу 413 |
| 400 | client sent too long header line |
раздутый заголовок (часто cookie сессии) |
| 400 | - | нет Host в HTTP/1.1; по HTTP/1.0 тот же запрос проходит |
| 499 | на уровне info |
клиент ушёл, не дождавшись ответа |
Приём: в строке 404 читай путь в кавычках - он показывает, как сложились
root/alias и URI. Половина ошибок видна прямо там.
Номер в скобках надёжнее фразы: (2:, (13:, (110: одинаковы везде, а
текст зависит от библиотеки C сборки (Operation timed out против
Connection timed out).
5xx
| Код | Строка | Причина |
|---|---|---|
| 502 | connect() failed (111: Connection refused) |
бэкенд не слушает |
| 502 | upstream prematurely closed connection while reading response header |
умер, не начав отвечать |
| 502 | upstream sent too big header |
не хватает proxy_buffer_size |
| 502 | no live upstreams |
все серверы группы помечены нерабочими |
| 504 | upstream timed out … while connecting/sending/reading |
этап написан в строке |
| 500 | rewrite or internal redirection cycle |
зациклился try_files/rewrite |
| 500 | us=500 |
ошибку отдал сам бэкенд |
| 503 | limiting requests, excess: … |
сработал свой же limit_req/limit_conn |
Точка невозврата
Подставить свой код nginx может только до первого байта заголовков ответа.
Оборвалось после - клиент получает 200 с обрезанным телом, в access_log ошибки
нет вовсе. Признак в логе: строка prematurely closed connection while reading
upstream без слова header, а в access_log - код 200 и $body_bytes_sent
меньше обещанного.
Точечные лимиты
location /api/upload {
client_max_body_size 100m; # только там, где реально принимают файлы
proxy_pass http://app:8000;
}
Ставить большой лимит на весь сервер - значит разрешить любому адресу занимать сто мегабайт памяти и диска на запрос.
Ловушки джокера
- 499 «чинят» на стороне nginx. Это клиент закрыл соединение - смотреть надо на время ответа бэкенда, а не на nginx.
- 502 сразу после выкладки - обычно бэкенд ещё не поднялся, а не «сломался
nginx». Ждать нечего, поэтому код 502, а не 504, и
urt=0.000. no live upstreamsпри одном сервере в группе не бывает. Единственный сервер nginx нерабочим не считает; строка появляется только когда выбыли все, и причина - в строках выше.- Разбор по коду без лога. У 403 три разные природы, и различает их только
строка в
error_log. proxy_read_timeout- пауза между чтениями, а не весь ответ. Ответ, идущий кусочками по три секунды, живёт при таймауте 5с сколько угодно долго.limiting requests(уровеньerror) - отказ,delaying request(уровеньwarn) - очередь. Второе означает, что люди просто ждали, и поднимать лимит незачем.
Комментарии
Пока нет комментариев. Будь первым!
Оставить комментарий