- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Bad Gateway говорит о том, что фронт-энд не достучался до бэк-энда, вы должны это знать.
Потому логи Апача бестолку смотреть.
Вы не правы. nginx передал запрос апачу, а тот не смог его обработать. Так что в логи апача смотреть нужно, очень вероятно, что запрос там будет.
Вы не правы. nginx передал запрос апачу, а тот не смог его обработать. Так что в логи апача смотреть нужно, очень вероятно, что запрос там будет.
чо, правда? :D
чо, правда?
а что, есть сомнения?
Вероятнее всего, конечно, апач был недоступен, но в логи посмотреть всегда полезно.
если логи nginx пишет, то запрос с статусом 502 ничем не отличается от других запросов и будет в логе, указанном директивой access_log. в error_log тоже что-нибудь окажется :)
а что, есть сомнения?
Вероятнее всего, конечно, апач был недоступен, но в логи посмотреть всегда полезно.
и очень сильные сомнения. тут выше уже отписали почему
Нигде не фиксируется. Это надо в nginx лезть.
Это он настолько убог, что ошибки, предусмотренные RFC не логгирует? Не, я не верю.
ТС, смотрите документацию веб-сервера. Общее правило: в access.log (если он включен) попадают все запросы, на которые клиенту ответили, а error.log - ведется параллельно, туда попадают сопутствующие обработке запросов ошибки. Для одной строчки в access.log - может быть несколько соответствующих в error.log.
Обратите внимание, если у вас несколько веб-серверов (типовая схема nginx + апач) - запрос (и ошибки) могут попасть в логи одного из них (первого).
Это он настолько убог, что ошибки, предусмотренные RFC не логгирует? Не, я не верю.
ТС, смотрите документацию веб-сервера. Общее правило: в access.log (если он включен) попадают все запросы, на которые клиенту ответили, а error.log - ведется параллельно, туда попадают сопутствующие обработке запросов ошибки. Для одной строчки в access.log - может быть несколько соответствующих в error.log.
Обратите внимание, если у вас несколько веб-серверов (типовая схема nginx + апач) - запрос (и ошибки) могут попасть в логи одного из них (первого).
Спасибо всем!
т.е. реально это можно показывать или нет в access.log? правильно? меня неа самом деле это больше волновало.
т.е. реально это можно показывать или нет в access.log?
Что значит "можно или нет"? По-умолчанию, если включен access.log - в него попадают все обработанные запросы.
Что значит "можно или нет"? По-умолчанию, если включен access.log - в него попадают все обработанные запросы.
У меня сегодня казус был - браузер ошибку выдал, а файле ее не нашел. Поэтому был удивлен... Такое может быть? Или хостер провайдер как то настроил...
У меня сегодня казус был - браузер ошибку выдал, а файле ее не нашел. Поэтому был удивлен... Такое может быть? Или хостер провайдер как то настроил...
Это вам в раздел телепатов.
Такое вполне может быть на виртуальном хостинге. Например, перед веб-сервером (апача, к примеру) с вашим сайтом у провайдера может стоять прокси, который и выдал ошибку. А вам дали доступ к логам апача.