O servidor da Web serve aleatoriamente diferentes fantasmas


9

O nginx está sendo executado no Ubuntu Trusty. Ele serve vários sites em https, rodando em um endereço IP.

Aleatoriamente, embora pareça um pouco relacionado à carga de trabalho, às vezes solicitações únicas aparecem no vhost errado. Isso leva a solicitações de lustrum.thalia.nuatendimento thalia.nue vice-versa. Isso gera páginas de erro desagradáveis, pois os usuários acabam subitamente em um site diferente. Quando você pressiona F5, os usuários acabam no destino original novamente.

Não parece relacionado ao navegador ou sistema operacional. Foi confirmado que isso acontece no Firefox (Linux, Windows, Mac), Edge (Windows) e Chrome (Linux, Windows, Android) e Safari (iOS).

O problema parece ocorrer com mais frequência quando o sistema é carregado, sugerindo algum tipo de condição de corrida.

lustrum.thalia.nu

server {
        server_name lustrum.thalia.nu;

        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/lustrum.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/lustrum.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia-lustrum/public_html;

        location / {
                index index.php;
                try_files $uri $uri/ /index.php?$args;
        }

        # Add trailing slash to */wp-admin requests.
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;

        # Pass all .php files onto a php-fpm/php-fcgi server.
        location ~ [^/]\.php(/|$) {
                include         /etc/nginx/fastcgi_params;

                fastcgi_split_path_info ^(.+?\.php)(/.*)$;

                if (!-f $document_root$fastcgi_script_name) {
                        return 404;
                }

                fastcgi_pass    unix:/var/run/php5-fpm-thalia-lustrum.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

thalia.nu

server {
        server_name thalia.nu;    
        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/www.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/www.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia/public_html;

        location / {
                try_files $uri $uri/ /index.php/$request_uri;
                index index.php index.html index.htm;
        }

        location ~ \.php($|/) {
                include         /etc/nginx/fastcgi_params;
                set  $script     $uri;
                set  $path_info  "";
                if ($uri ~ "^(.+\.php)(/.+)") {
                                set  $script     $1;
                                set  $path_info  $2;
                }
                fastcgi_read_timeout    120;
                fastcgi_pass    unix:/var/run/php5-fpm-thalia-www.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

Como você pode ver, estamos executando diferentes pools de PHP5-FPM para esses dois domínios. Esses pools são chrootados para diferentes pastas e executados como usuários diferentes. De outra forma, a configuração do PHP-FPM é bastante padrão, até onde eu sei.

Tentamos o nginx 1.4.6-ubuntu3 e o nginx 1.8.0-1 + confiável.

Telemetria de log

266.266.266.266 - - [25/Nov/2015:09:24:40 +0100] "GET /committees/175 HTTP/1.1" 302 5 "https://thalia.nu/committees" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0" Host: "thalia.nu" Location: "https://thalia.nu/index.php//committees/wp-admin/setup-config.php"

Nesta linha, você pode ver que a solicitação para a página /committeesrepentinamente é redirecionada wp-admin. Parece que a solicitação de /committeesfoi tratada pelo thalia-lustrumpool PHP-fpm ...

Arquivo de zona DNS

Não vemos como isso pode ser relevante, mas ...

;; MX Records
thalia.nu.    300    IN    MX    20    relay.transip.nl.
thalia.nu.    300    IN    MX    10    ivo.thalia.nu.

;; TXT Records
thalia.nu.    300    IN    TXT    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; SPF Records (Sender Policy Framework)
thalia.nu.    300    IN    SPF    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; CNAME Records
lustrum.thalia.nu.    300    IN    CNAME    thalia.nu.

;; A Records (IPv4 addresses)
thalia.nu.    300    IN    A    131.174.31.8
www.thalia.nu.    300    IN    A    131.174.31.8
ivo.thalia.nu.    300    IN    A    131.174.31.8

1
Por favor, verifique suas configurações de DNS para os domínios.
Diamante

1
@bangal são um registro A e CNAME, apontando para o mesmo IP. Não vejo como isso está relacionado; isso resolve muito bem e parece improvável que um problema de DNS se manifeste de maneira inconsistente.
Joost

2
@ThomWiggers, você pode adicionar ao seu arquivo de log o conteúdo do Host:cabeçalho http e do agente do usuário? Veja aqui como: serverfault.com/questions/636790/… . Na verdade, tentei fazer alguns pedidos em seus sites, mas não reproduzimos seu problema. Qual cliente você está usando para reproduzir isso?
Freded Fredi

3
O fato de eu ter acabado de receber "Conteúdo de terceiros não instalado" ou algo assim porque você está trabalhando nele ou acabei em outro pool PHP ou algo assim (acionando o mesmo bug)? Também recebi um breve erro sobre config.phpnão encontrado.
Halfgaar 25/11/2015

2
@kasperd serverfault.com/questions/737349/… . Parece afetar apenas os scripts PHP.
Thom Wiggers

Respostas:


4

Depois de horas depurando esse problema, finalmente conseguimos rastrear a causa. Parece que a causa não é nginx, mas PHP-fpm. Estamos executando a php5-fpmversão 5.5.9-1ubuntu4.14. Parece que, quando bifurcando novos trabalhadores, algo às vezes dá errado e os trabalhadores executam (parte?) Do código de diferentes trabalhadores.

Nossa solução foi copiar /etc/php5/fpm/php5-fpm.confpara cópias diferentes com suas próprias pool.dpastas e depois copiar /etc/init.d/php5-fpmpara iniciar com o novo arquivo de configuração (também criando arquivos /etc/init/). Isso significa que agora temos um php5-fpmgerenciador de processos por pool. Ter chroots e soquetes separados não parece manter as coisas separadas o suficiente.


Observe que atualmente não está claro se isso é um problema em nossa configuração ou (nesta versão do) php5-fpm, embora o último não pareça provável devido à falta de relatórios semelhantes. Se acabarmos descobrindo o motivo pelo qual esse problema ocorre, essa resposta será atualizada.
Joost

1

Estou enfrentando o mesmo problema, mas no Debian com Apache2.4.25 e PHP7.1-FPM. Aqui está uma maneira de separar processos https://ma.ttias.be/a-better-way-to-run-php-fpm/

Para aqueles como eu, que podem achar essa solução muito pesada para sites pequenos, adicione php_admin_value[opcache.revalidate_freq] = 0no final do arquivo de configuração do pool php-fpm. No entanto, isso pode ter um sério impacto nas performances ...

Aqui está o relatório oficial de bug: https://bugs.php.net/bug.php?id=67141


0

O Nginx suporta SNI? Você pode executar o nginx -V e deve ver algo como o suporte TLS SNI ativado. Caso contrário, talvez seja por isso, porque o nome do host é enviado após o aperto de mão e estou assumindo que você tenha um certificado curinga para * .thalia.nu


Claro que sim, sem o SNI, isso daria errado 100% do tempo, em vez de muito ocasionalmente. (e eu também tenho verificado isso, é definitivamente habilitado)
Thom Wiggers

FWIW, observe que não servimos um certificado curinga, mas usamos certificados individuais para os subdomínios separados. Isso está incluído na configuração listada na pergunta.
Joost

.. embora o certificado lustrum.thalia.nu também seja válido para Thalia.nu
Thom Wiggers

Você pode tentar adicionar o parâmetro includeSubDomains como este? add_header Strict-Transport-Security "max-age = 63072000; includeSubDomains; preload";
Mugurel

@ThomWiggers Se o certificado for válido para vários domínios, é possível oferecer suporte a vários domínios em um único IP sem a necessidade de SNI.
kasperd

-1

Parece que o certificado não está certo: o Firefox está me dizendo que foi emitido para www.thalia.nu, não thalia.nu.

Este é o IMHO que está causando problemas. Tente com outro certificado ou tente ativar conexões HTTP sem SSL.


Não podemos reproduzir isso. O certificado serviu em www.thalia.nue thalia.nuinclui os dois domínios, com e sem www. Qual versão do Firefox você está usando e em qual plataforma?
Joost
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.