Веб-сервер случайным образом обслуживает разных Vhosts

У нас работает nginx на Ubuntu Trusty. Он обслуживает несколько веб-сайтов по https и работает по одному IP-адресу.

Случайно, хотя кажется, что это немного связано с рабочей нагрузкой, иногда отдельные запросы появляются не на том хосте. Это приводит к запросам на lustrum.thalia.nuобслуживание thalia.nuи наоборот. Это дает неприятные страницы с сообщениями об ошибках, поскольку пользователи неожиданно попадают на другой веб-сайт. Когда вы нажимаете F5, пользователи снова оказываются в исходной цели.

Это не похоже на браузер или операционную систему. Это было подтверждено в Firefox (Linux, Windows, Mac), Edge (Windows) и Chrome (Linux, Windows, Android) и Safari (iOS).

Эта проблема возникает чаще, когда система находится под нагрузкой, что указывает на какое-то состояние гонки.

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

Как видите, мы используем разные пулы PHP5-FPM для этих двух доменов. Эти пулы привязаны к разным папкам и работают как разные пользователи. Насколько я могу судить, конфигурация PHP-FPM в остальном довольно стандартна.

Мы попробовали оба nginx 1.4.6-ubuntu3 и nginx 1.8.0-1 + trusty.

Журнал телеметрии

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"

В этой строке вы видите, что запрос на страницу /committeesвнезапно перенаправляется на wp-admin. Похоже, что запрос /committeesобработан thalia-lustrumпулом PHP-fpm ...

Файл зоны DNS

Мы не видим, как это может быть актуально, но ...

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

После нескольких часов отладки этой проблемы мы наконец смогли отследить ее причину. Кажется, причина не в этом nginx, а в PHP-fpm. Мы запускаем php5-fpmверсию 5.5.9-1ubuntu4.14. Похоже, что при разветвлении новых работников что-то иногда идет не так, и работники запускают (частично?) Кодекс разных работников.

Нашим решением было копировать /etc/php5/fpm/php5-fpm.confв разные копии с собственными pool.dпапками, а затем копировать /etc/init.d/php5-fpmдля запуска с новым файлом конфигурации (также создавая файлы в /etc/init/). Это означает, что теперь у нас есть php5-fpmдиспетчер процессов на пул. Наличие отдельных chroot и сокетов, кажется, не держит вещи отдельно.

Я сталкиваюсь с той же проблемой, но на Debian с Apache2.4.25 и PHP7.1-FPM. Вот способ разделить процессы https://ma.ttias.be/a-better-way-to-run-php-fpm/

Для тех, кто, как я, может найти это решение слишком тяжелым для небольших веб-сайтов, добавьте php_admin_value[opcache.revalidate_freq] = 0в конец конфигурационный файл пула php-fpm. Однако это может оказать серьезное влияние на выступления ...

Вот официальный отчет об ошибке: https://bugs.php.net/bug.php?id=67141

Поддерживает ли Nginx SNI? Вы можете запустить nginx -V и увидеть что-то вроде поддержки TLS SNI. Если вы этого не сделаете, возможно, это потому, что имя хоста отправляется после рукопожатия, и я предполагаю, что у вас есть подстановочный сертификат для * .thalia.nu

Кажется, что сертификат не прав: firefox говорит мне, что он выдан для www.thalia.nu, а не thalia.nu.

Это ИМХО, что вызывает проблемы. Попробуйте использовать другой сертификат или активируйте HTTP-соединения без SSL.