Я приступил к работе над проблемой, с которой раньше не сталкивался, и мне было любопытно посмотреть, есть ли у кого-нибудь из присутствующих какие-нибудь идеи о том, что могло ее вызвать.
Мы запускаем VPS от Slicehost, и где-то вчера сайты, которые мы размещаем, отключились (после правильной работы в течение нескольких месяцев с тех пор, как я что-то делал с сервером), но только через HTTP (с использованием порта 8080). Сайты HTTPS (стандартный порт) все еще работали, если доступ к ним был осуществлен специально с помощью https://site.com (вместо того, чтобы вводить site.com и разрешать перенаправлениям делать работу), а также подключения SSH непосредственно к серверу.
Так оставалось до сегодняшнего утра. Я перезагрузил сервер, но это не помогло. Я подключился к нему через SSH и убедился, что все работает правильно. В журналах Nginx или других журналах, которые я проверял, не было никаких необычных сообщений об ошибках. Тем не менее, ничего не изменилось. Затем внезапно, примерно через полчаса после того, как я это сделал, пока я искал причину, сайты снова начали работать.
Я так и не нашел ничего о том, что могло вызвать проблему (все, что я обнаружил, было проблемами на стороне клиента), поэтому мне было любопытно, что могло потенциально вызвать проблему. Так я смогу лучше диагностировать и исправить, если что-то подобное случится снова.
Практически что угодно могло вызвать проблему. Если только у кого-то действительно не возникла эта точная проблема по той же причине, вы, вероятно, не получите решения поставленного вами вопроса.
Однако вот несколько советов по диагностике, которые помогут вам найти причину проблемы в следующий раз:
tcpdump -i ethN -n port 8080
и попробуйте сделать запрос. Если tcpdump
ничего не показывает, проблема в сети. Hassle Softlayer.iptables -L INPUT -v >/tmp/before
, попал на сайт, беги iptables -L INPUT -v >/tmp/after
, а потом diff /tmp/before /tmp/after
. Любые различия в количестве пакетов / байтов указывают на возможно правило брандмауэра, блокирующее трафик. Вам нужно будет проверить каждое правило, чтобы определить, является ли оно причиной проблемы. (Вот почему неплохо регистрировать блокировки брандмауэра; это значительно упрощает подобные вещи).netstat -ltnp |grep :8080
чтобы убедиться, что nginx на самом деле прослушивает интересующий порт, и что он прослушивает правильный IP-адрес. Не принимайте ничего как должное на этом этапе игры.strace
процессы nginx (strace -p <pid> -p <pid>
для всех, кто связан с nginx) и убедитесь, получают ли они трафик, и посмотрите, что (и что) они с этим делают.