Etapas para solucionar novas instalações do Nginx

3

Eu estou configurando o Nginx em um novo servidor rodando o Ubuntu 12.04. Aqui está o que eu fiz até agora:

  1. nginx instalado:

    aptitude -y install nginx
    
  2. Removida a configuração padrão do vhost:

    rm /etc/nginx/sites-enabled/*
    
  3. Adicionada minha própria configuração vhost:

    mv myapp.conf /etc/nginx/sites-enabled/
    
  4. Iniciado nginx:

    service nginx start
    

O arquivo vhost se parece com algo assim:

upstream unicorn_server {
  server unix:/tmp/APP_NAME.sock fail_timeout=0;
}

server {
  listen 80 default deferred;
  client_max_body_size 4G;
  server_name _;
  keepalive_timeout 5;
  access_log  /var/log/nginx/APP_NAME.access.log;

  root /var/www/APP_NAME/current/public;

  # auth

  try_files $uri/index.html $uri.html $uri @app;

  location @app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://unicorn_server;
  }

  error_page 500 502 503 504 /500.html;
  location = /500.html {
    root /var/www/APP_NAME/current/public;
  }
}

Posso confirmar que o Nginx está em execução:

service nginx status
 * nginx is running

No entanto, parece que não consigo acessá-lo:

curl 123.456.789.0 # example IP
curl: (7) couldn't connect to host

Ainda não iniciei o servidor de unicórnios, mas isso não deve ser um problema. Espero ver um erro 502 se o Unicorn não estiver em execução. Não há saída no erro ou nos logs de acesso. Que passos devo seguir para resolver o problema?

    
por Andrew 02.12.2013 / 07:21

3 respostas

2
  • execute nginx -t no arquivo de configuração
  • Verifique os arquivos de log - os que você especificou e os possíveis "padrão" que o nginx grava se não puder usar os especificados, antes de carregar a configuração, ou se parecer, e claro, logs globais que podem conter mensagens de erro
  • pare o nginx e inicie-o manualmente (ou seja, não use o script de inicialização) e procure a saída. Mate seu nginx e inicie-o usando o script init depois.
  • Verifique o netstat se ele mostra nginx ouvindo ou não. Se não, não se incomode em testar se é alcançável, encontre a causa. Se estiver escutando, teste-o localmente (wget) para descobrir se o nginx ou a conectividade está quebrada.
  • Se não doer (ou seja, nada mais em execução na máquina), tente reinicializá-lo.
por 08.12.2013 / 03:51
3

A única coisa realmente incomum sobre essa configuração que você postou é o uso de deferred na sua diretiva listen .

Parece que alguns sites fornecem isso em suas configurações de amostra e "recomendam", mas na verdade não explicam o que ele faz . (O que não é muito, a menos que seja definido em ambas as extremidades, e se não for, então as coisas ficam muito estranhas muito rápido, já que isso tecnicamente quebra sutilmente o protocolo TCP.)

A primeira coisa que eu faria seria remover essa opção deferred da sua diretiva listen .

Mesmo que isso não resolva o problema, eu não o colocaria de volta. Se você quiser investigar seus supostos benefícios de desempenho posteriormente, poderá fazê-lo em um ambiente de teste cuidadosamente controlado.

    
por 05.12.2013 / 07:28
0

Firewall no seu servidor bloqueando a conexão com 80 portas? Tente fazer 'curl localhost' no servidor para verificar se ele está acessível localmente.

    
por 10.12.2013 / 14:40

Tags