Le serveur Web sert aléatoirement différents vhosts

Nous avons nginx en cours d'exécution sur Ubuntu Trusty. Il dessert plusieurs sites Web via https, fonctionnant sur une seule adresse IP.

Au hasard, bien que cela semble légèrement lié à la charge de travail, des requêtes uniques se présentent parfois sur le mauvais vhost. Cela conduit à des demandes d' lustrum.thalia.nuêtre servi par thalia.nuet vice-versa. Cela donne alors des pages d'erreur désagréables car les utilisateurs se retrouvent soudainement sur un site Web différent. Lorsque vous appuyez sur F5, les utilisateurs se retrouvent à nouveau sur la cible d'origine.

Il ne semble pas lié au navigateur ou au système d'exploitation. Il a été confirmé que cela se produisait sur Firefox (Linux, Windows, Mac), Edge (Windows) et Chrome (Linux, Windows, Android) et Safari (iOS).

Le problème semble se produire plus fréquemment lorsque le système est mis sous charge, ce qui suggère une sorte de condition de concurrence.

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;
        }
}

Comme vous pouvez le voir, nous exécutons différents pools PHP5-FPM pour ces deux domaines. Ces pools sont chrootés dans différents dossiers et s'exécutent en tant qu'utilisateurs différents. La configuration de PHP-FPM est par ailleurs assez standard pour autant que je sache.

Nous avons essayé nginx 1.4.6-ubuntu3 et nginx 1.8.0-1 + trusty.

Télémétrie des journaux

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"

Sur cette ligne, vous pouvez voir que la demande de page est /committeessoudainement redirigée vers wp-admin. Il semble que la demande de /committeessoit traitée par le thalia-lustrumpool PHP-fpm ...

Fichier de zone DNS

Nous ne voyons pas en quoi cela peut être pertinent, mais ...

;; 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

Après des heures de débogage de ce problème, nous avons finalement pu le retrouver jusqu'à la cause. Il semble que la cause ne soit pas nginx, mais PHP-fpm. Nous exécutons la php5-fpmversion 5.5.9-1ubuntu4.14. Il semble que lors de la recherche de nouveaux travailleurs, quelque chose se passe parfois mal et les travailleurs exécutent (en partie?) Le code des différents travailleurs.

Notre solution était de copier /etc/php5/fpm/php5-fpm.confsur différentes copies avec leurs propres pool.ddossiers, puis de copier /etc/init.d/php5-fpmpour lancer avec le nouveau fichier de configuration (créant également des fichiers dans /etc/init/). Cela signifie que nous avons maintenant un php5-fpmgestionnaire de processus par pool. Le fait d'avoir des chroots et des sockets séparés ne semble pas séparer suffisamment les choses.

Je suis confronté au même problème mais sur Debian avec Apache2.4.25 et PHP7.1-FPM. Voici un moyen de séparer les processus https://ma.ttias.be/a-better-way-to-run-php-fpm/

Pour ceux comme moi qui pourraient trouver cette solution trop lourde pour les petits sites Web, ajoutez php_admin_value[opcache.revalidate_freq] = 0à la fin du fichier de configuration du pool php-fpm. Cependant, cela peut avoir un impact sérieux sur les performances ...

Voici le rapport de bogue officiel: https://bugs.php.net/bug.php?id=67141

Nginx prend-il en charge SNI? Vous pouvez exécuter nginx -V et devriez voir quelque chose comme le support TLS SNI activé. Si vous ne le faites pas, c'est peut- être la raison pour laquelle le nom d'hôte est envoyé après la poignée de main et je suppose que vous disposez d'un certificat générique pour * .thalia.nu

Il semble que le certificat ne soit pas correct: Firefox me dit qu'il est délivré pour www.thalia.nu, pas thalia.nu.

C'est à mon humble avis ce qui cause des problèmes. Essayez avec un autre certificat ou essayez d'activer les connexions HTTP sans SSL.