Отказ подключения — одна из причин 502. Здесь — как по строке error.log отличить остальные.
Приложение может слушать не порт, а файл — unix-сокет. Тогда в proxy_pass стоит путь к нему: proxy_pass http://unix:/run/app/app.sock;. Подключиться к сокету может процесс с правом записи в этот файл. Рабочие процессы nginx в Ubuntu работают от пользователя www-data — право нужно ему.
Что случилось на втором участке, видно по словам в строке error.log:
| В строке error.log | Что случилось |
|---|---|
(111: Connection refused) while connecting to upstream |
по адресу и порту из proxy_pass никто не слушает |
(2: No such file or directory) while connecting to upstream |
файла сокета по этому пути нет |
(13: Permission denied) while connecting to upstream |
сокет есть, но у www-data нет права записи в него |
upstream timed out (110: Connection timed out) |
приложение не ответило вовремя — 504 Gateway Time-out |
В error.log строка connect() to unix:/run/shop/shop.sock failed (13: Permission denied) while connecting to upstream. Что проверишь первым?
-
В
proxy_passздесь путь к сокету, порта в нём нет. Файл nginx нашёл — иначе в скобках было бы2: No such file or directory. -
Тайм-аут пишется другой строкой —
upstream timed out. Код 13 — отказ в доступе сразу при подключении. -
Код 13 говорит о правах на файл: без них nginx не дойдёт до приложения, работает оно или нет. Права покажет
ls -lна сокет.
Код 13 — отказ в доступе: файл сокета есть, но рабочим процессам nginx от www-data не хватает права записи в него. Права смотрят ls -l на сокет и на каталог над ним.
Главное в шаге
- Код в скобках в строке error.log называет причину: 111 — никто не слушает, 2 — нет файла сокета, 13 — нет прав.
-
К unix-сокету подключаются рабочие процессы nginx от
www-data: право записи нужно им. -
Приложение, которое не ответило вовремя, даёт клиенту другой код —
504 Gateway Time-out.