Nginx не прослушивает порт 80

Я только что установил сервер Ubuntu 12.04 и nginx 1.2.7, удалил default с сайтов и добавил свой собственный файл в sites-available и символическую ссылку в sites-enabled. Затем перезапустили nginx.

Проблема: Однако при переходе на URL-адрес не загружается сайт. netstat -nlp | grep nginx и netstat -nlp | grep 80 оба не возвращают результата! lsof -i :80 также ничего не возвращает. A dig с другого сервера возвращает правильный IP-адрес, поэтому он не должен быть проблемой DNS. Мне удалось подключиться к apache, который я сейчас прекратил. Журналы nginx также ничего не показывают.

Как устранить эту проблему?

/etc/nginx/site-available/mysite.com

server {
    listen   80;
    server_name www.mysite.com mysite.com *.mysite.com;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    root /var/www/mysite/public;

    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args ;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_read_timeout 300;
    }

}

Ответ 1

У меня была такая же проблема, решение заключалось в том, что я не правильно привязал свой файл siteconf. Попробуйте запустить vim /etc/nginx/sites-enabled/mysite.com - вы можете добраться до него? Я получаю "Разрешение отклонено".

Если не запустить:

rm /etc/nginx/sites-enabled/mysite.com
ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/mysite.com

Ответ 2

Если в ваших журналах ничего не говорится об этой проблеме, вы не можете включать каталог с поддержкой сайтов. Один простой способ сказать, что сайт загружается, - установить путь журнала ошибок/доступа в пределах вашего блока сервера к уникальному пути, перезагрузить nginx и проверить, созданы ли файлы.

Убедитесь, что в контексте http в /etc/nginx/nginx.conf существует директива include include.

http {
  ...
  include /etc/nginx/sites-enabled/*;
}

Ответ 3

Я столкнулся с той же проблемой, я получил ошибку Failed to load resource: net::ERR_CONNECTION_REFUSED при подключении через HTTP, но отлично по HTTPS. Ran netstat -tulpn и увидел, что nginx не привязан к порту 80 для IPv4. Сделано все, что описано здесь. Оказалось, что это что-то очень глупо:

Убедитесь, что файл sites-available с default_server действительно включен.

Надеюсь, что это немного спасло другого бедного идиота.

Ответ 4

Вы, вероятно, дважды привязываете nginx к порту 80. Это ваш полный файл конфигурации? У вас нет другого заявления, слушая порт 80?

Ответ 5

Я нашел полезным подойти к отладке nginx со следующими шагами:

1... Убедитесь, что nginx запущен.

ps aux | grep nginx

2... Проверьте процессы, уже связанные с данным портом.

lsof -n -i:80

3... Убедитесь, что nginx был перезагружен.

sudo nginx -t
sudo nginx -s reload

На Mac, brew services restart nginx не достаточно, чтобы перезагрузить Nginx.

4... Попробуйте создать простые ответы вручную, чтобы убедиться, что путь к вашему местоположению не перепутан. Это особенно полезно, когда возникают проблемы при использовании proxy_pass для пересылки запросов другим запущенным приложениям.

location / {
    add_header Content-Type text/html;
    return 200 'Here I am!';
}

Ответ 6

Полуколона ; отсутствует в /etc/nginx/nginx.conf для примера на линии до include /etc/nginx/servers-enabled/*; может просто обойти эту конструкцию, а проверка nginx -t в любом случае будет успешной.

Итак, просто проверьте, что все команды в /etc/nginx/nginx.conf заканчиваются точкой с запятой ;.

Ответ 7

Вы проверили, действительно ли существует ваш nginx-бинарный файл? проверьте,

#whereis nginx

выводит двоичный путь и проверяет этот путь с помощью init script от /etc/init.d/nginx. например.

DAEMON=/usr/sbin/nginx

(В моем init script "test -x $DAEMON || exit 0" вызывается и в любом случае этот script ничего не возвращает - мой двоичный файл полностью отсутствует)

Ответ 8

В моем случае эти выходные данные сетевых команд показали, что nginx правильно связывался с портом 80, но порты не были внешне доступны или не видны с помощью nmap.

Хотя я подозревал брандмауэр, оказалось, что старые правила iptables на машине перенаправляли трафик с этих портов и конфликтовали с nginx. Используйте sudo iptables-save для просмотра всех действующих на данный момент правил.

Ответ 9

Хотя мы все думаем, что не делаем глупых ошибок, мы делаем.

Итак, если вы изучаете проблемы с NGINX и все признаки показывают, что он должен работать, то вам следует отойти от файлов и посмотреть вниз по течению.

Системный брандмауэр, аппаратный брандмауэр, маршрутизатор/межсетевой экран Nat.

Для меня этой проблемой был мой маршрутизатор, я управляю домашней лабораторией и поэтому могу издалека получать доступ к службам за моим маршрутизатором. Я использую NGINX для обратного прокси-сервера, поскольку мой маршрутизатор обрабатывает только входящие сообщения на основе IP и не обрабатывает имена хостов, я Я уверен, что это все нормально.

В любом случае моя проблема возникла, когда я защищал свою сеть несколько дней назад, удалив переадресацию портов, которая больше не нужна, и я случайно удалил порт 80.

Да, это было так же просто, как переадресация этого порта в NGINX, и все было исправлено.

Теперь я уйду с опущенной головой в крайнем позоре, хотя оставляю этот ответ, чтобы показать свою благодарность людям в этой теме, которые заставили меня найти свою собственную ошибку.

Так что спасибо тебе.