Serwer WWW losowo obsługuje różne vhosty

Mamy nginx działający na Ubuntu Trusty. Obsługuje kilka stron internetowych przez https, działających na jednym adresie IP.

Losowo, chociaż wydaje się, że jest to nieco związane z obciążeniem pracą, czasem pojedyncze żądania pojawiają się na niewłaściwym vhostie. Prowadzi to do wniosków o lustrum.thalia.nudoręczenie thalia.nui odwrotnie. To powoduje nieprzyjemne strony błędów, gdy użytkownicy nagle trafiają na inną stronę internetową. Gdy naciśniesz F5, użytkownicy ponownie znajdą się na pierwotnym celu.

Nie wydaje się, aby był związany z przeglądarką lub systemem operacyjnym. Potwierdzono, że dzieje się to w Firefox (Linux, Windows, Mac), Edge (Windows) i Chrome (Linux, Windows, Android) i Safari (iOS).

Problem pojawia się częściej, gdy system jest obciążony, co sugeruje jakiś rodzaj wyścigu.

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

Jak widać, uruchomiliśmy różne pule PHP5-FPM dla tych dwóch domen. Pule te są chrootowane do różnych folderów i działają jako różni użytkownicy. Konfiguracja PHP-FPM jest poza tym dość standardowa, o ile wiem.

Wypróbowaliśmy zarówno wersję nginx 1.4.6-ubuntu3, jak i nginx 1.8.0-1 +.

Rejestruj dane telemetryczne

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"

W tym wierszu widać, że żądanie strony /committeesnagle zostaje przekierowane wp-admin. Wygląda na to, że żądanie /committeeszostało obsłużone przez thalia-lustrumpulę PHP-fpm ...

Plik strefy DNS

Nie wiemy, jak to może być istotne, ale ...

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

Po godzinach debugowania tego problemu w końcu udało nam się prześledzić przyczynę. Wydaje się, że przyczyną nie jest nginx, ale PHP-fpm. Uruchamiamy php5-fpmwersję 5.5.9-1ubuntu4.14. Wydaje się, że przy rozwidlaniu nowych pracowników czasami coś idzie nie tak i pracownicy uruchamiają (część?) Kod różnych pracowników.

Naszym rozwiązaniem było kopiowanie /etc/php5/fpm/php5-fpm.confdo różnych kopii z własnymi pool.dfolderami, a następnie kopiowanie w /etc/init.d/php5-fpmcelu uruchomienia z nowym plikiem konfiguracyjnym (także tworzenie plików w /etc/init/). Oznacza to, że mamy teraz php5-fpmmenedżera procesów dla każdej puli. Posiadanie osobnych chrootów i gniazd nie wydaje się, aby trzymać rzeczy wystarczająco osobno.

Mam ten sam problem, ale na Debianie z Apache2.4.25 i PHP7.1-FPM. Oto sposób na oddzielne procesy https://ma.ttias.be/a-better-way-to-run-php-fpm/

Dla takich jak ja, którzy mogą uznać to rozwiązanie za zbyt ciężkie dla małych stron internetowych, dodaj php_admin_value[opcache.revalidate_freq] = 0na końcu pliku konfiguracyjnego puli php-fpm. Może to jednak mieć poważny wpływ na wyniki ...

Oto oficjalny raport o błędzie: https://bugs.php.net/bug.php?id=67141

Czy Nginx obsługuje SNI? Możesz uruchomić nginx -V i powinieneś zobaczyć włączoną obsługę TLS SNI. Jeśli nie, być może dlatego, że nazwa hosta jest wysyłana po uzgadnianiu i zakładam, że masz certyfikat wieloznaczny dla * .thalia.nu

Wygląda na to, że certyfikat nie jest poprawny: Firefox mówi mi, że został wydany dla www.thalia.nu, a nie thalia.nu.

To IMHO powoduje problemy. Spróbuj użyć innego certyfikatu lub spróbuj aktywować połączenia HTTP bez SSL.