O servidor da Web serve aleatoriamente diferentes fantasmas

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

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.

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

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

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.