Serwer WWW losowo obsługuje różne vhosty


9

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

1
Plesse sprawdź ustawienia DNS dla domen.
Diament

1
@ bangal są rekordami A i CNAME, wskazującymi na ten sam adres IP. Nie rozumiem jednak, jak to się wiąże; rozwiązują to dobrze i wydaje się mało prawdopodobne, aby problem z DNS pojawił się tak niekonsekwentnie.
Joost

2
@ThomWiggers, czy możesz dodać do swojego pliku dziennika zawartość Host:nagłówka http i agenta użytkownika? Zobacz tutaj, jak: serverfault.com/questions/636790/… . Właściwie próbowałem przesłać jakieś prośby do twoich stron, ale nie mogłem odtworzyć twojego problemu. Jakiego klienta używasz do tego?
Fredi

3
Czy fakt, że właśnie dostałem „Treści innych firm nie zostały zainstalowane” czy coś takiego, ponieważ nad tym pracujesz, czy też skończyło się na innej puli PHP lub coś takiego (powodując ten sam błąd)? Dostałem również krótki błąd dotyczący config.phpbraku znalezienia.
Halfgaar,

2
@kasperd serverfault.com/questions/737349/… . Wydaje się, że wpływa tylko na skrypty PHP.
Thom Wiggers,

Odpowiedzi:


4

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.


Zauważ, że obecnie nie jest jasne, czy jest to problem w naszej konfiguracji lub w (tej wersji) php5-fpm, chociaż ta ostatnia nie wydaje się prawdopodobna, biorąc pod uwagę brak podobnych raportów. Jeśli w końcu znajdziemy przyczynę tego problemu, odpowiedź zostanie zaktualizowana.
Joost

1

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


0

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


Oczywiście, że tak, bez SNI byłoby to błędne w 100% przypadków, a nie bardzo rzadko. (i sprawdziłem również, to jest zdecydowanie włączone)
Thom Wiggers

FWIW, pamiętaj, że nie obsługujemy certyfikatu wieloznacznego, ale używamy indywidualnych certyfikatów dla oddzielnych poddomen. Jest to uwzględnione w konfiguracji wymienionej w pytaniu.
Joost

.. chociaż certyfikat lustrum.thalia.nu jest również ważny dla Thalia.nu
Thom Wiggers

Czy możesz spróbować dodać parametr includeSubDomains w ten sposób? add_header Strict-Transport-Security "max-age = 63072000; includeSubDomains; preload";
Mugurel

@ThomWiggers Jeśli certyfikat jest ważny dla wielu domen, możliwe jest obsługiwanie wielu domen pod jednym adresem IP bez potrzeby korzystania z SNI.
kasperd

-1

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.


Nie możemy tego odtworzyć. Certyfikat serwowane www.thalia.nui thalia.nuobejmują zarówno domen, z lub bez www. Jakiej wersji Firefox używasz i na jakiej platformie?
Joost,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.