Why is my server slow and SSL mismatching when combining IPv4 with IPv6

Asked 17/9, 2018 at 6:47 Answered 23/9, 2018 at 22:43

I'm setting up a new server with Ubuntu 18.04.1 Nginx 1.14.0 with HTTP2 and PHP 7.2.7 This is the first server that I try to setup with both IPv4 and IPv6 enabled. Everything works fine until I tested a page with a lot of missing images. It seems to take forever for the server to realise they are missing and respond to the http request. Some missing files give a HTTP status of "502 bad gateway". Is it a DNS problem that causes these delays and 502 errors and what should I change in the setup?

Edit: there may be a lot of unneccesary info down here, but as it is not yet clear why the server reacts too slow, some of it may be of importance.

The php script should not be the problem, my old server, with the exact same page, loads very quick.

The zone file has records to both IPv4 and IPv6.

Edit: the whole DNS theory below is probably not the cause, see: Why does this nginx server redirect to a wrong domain?. The server redirects to a wrong domain. When forcing the nginx server only to listen to IPv4 and surfing to server1.eu there's a SSL certificate mismatch (only valid for server2.eu) and after forcing accept the certificate there's a 301 redirect to server2.eu Now, when I remove the server "server2.eu" from sites-enabled and reload nginx, the SSL certificate mismatch and redirect doesn't happen. With server "server2.eu" removed from sites-enabled, and server1.eu server IPv4 disabled in nginx server setup, it results in "no connection to server" when browsing to server1.eu With server "server2.eu" removed from sites-enabled, and server1.eu server IPv6 disabled from nginx server setup, it results in a slow server. Then I restore the server2.eu server again and disable server1.eu server IPv4 from nginx server setup, result: SSL certificate mismatch (only valid for server2.eu) and after forcing accept certificate 301 redirect to server2.eu Disabling server1.eu server IPv6 from nginx server setup results in a fast server, the 'slow server' problem is solved and so server1.eu is dependent on the wrong server to work normal. Meanwhile the IPv6 address [2a03:b0c0:0:1010::190:6001] still redirects to server1.eu

Edit: One difference in servers is the old has http1.1 and the new http2. Disabling http2 solves the extreme long loading and 502 errors. Still loading time for the page remains longer than old server (6.40 vs 3.18 sec)

When increasing settings in /etc/php/7.2/fpm/pool.d/www.conf, errors go away and loading time is still long: 8,4 seconds versus 3,16 seconds, but comes closer to the old server:

pm.max_children = 100
pm.start_servers = 20
pm.min_spare_servers = 20
pm.max_spare_servers = 30

The old server is IPv4 enabled only, HTTP 1.1, has less free memory, PHP version 5.5.9-1 Ubuntu 14.04.5 LTS and Nginx 1.4.6. and it's settings are:

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

New server curl

root@host:~# curl https://server1.eu/portfolio-2 > curltest.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11104    0 11104    0     0  31103      0 --:--:-- --:--:-- --:--:-- 31103
root@host:~# curl -4 https://server1.eu/portfolio-2 > curltest.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11104    0 11104    0     0  99142      0 --:--:-- --:--:-- --:--:-- 99142
root@host:~# curl -6 https://server1.eu/portfolio-2 > curltest.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11104    0 11104    0     0   101k      0 --:--:-- --:--:-- --:--:--  101k

Old server curl

root@server1:~# curl https://server1.eu/portfolio-2 > curltest.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11088    0 11088    0     0  49681      0 --:--:-- --:--:-- --:--:-- 49721

Edit: find /etc/nginx/{conf.d,sites-enabled} gives

/etc/nginx/sites-enabled/server1.eu 
/etc/nginx/sites-enabled/server2.eu

Edit: find /etc/nginx/{conf.d,sites-enabled} | xargs fgrep listen gives

/etc/nginx/sites-enabled/server1.eu:    listen 80 default_server;
/etc/nginx/sites-enabled/server1.eu:    listen [::]:80 default_server;
/etc/nginx/sites-enabled/server1.eu:               listen 443 ssl http2 default_server;
/etc/nginx/sites-enabled/server1.eu:               listen [::]:443 ssl http2 default_server;
/etc/nginx/sites-enabled/server2.eu:    listen 80;
/etc/nginx/sites-enabled/server2.eu:    listen [::]:80;
/etc/nginx/sites-enabled/server2.eu:            listen 443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen [::]:443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen 443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen [::]:443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen 443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen [::]:443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen 443 ssl http2;
/etc/nginx/sites-enabled/server2.eu:            listen [::]:443 ssl http2;

The hosts file might be a problem, however the problem persists if the hosts file is emptied all together. Here is the contents:

127.0.0.1 localhost
::1 localhost
2a03:b0c0:0:1010::190:6001 localhost
#host.server1.eu is the hostname of the server
127.0.1.1 host.server1.eu 
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Below is the nginx server configuration:

server {
    listen 80;
    listen [::]:80;
    return 301 https://server1.eu;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        ssl_certificate /etc/letsencrypt/live/server1.eu/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/server1.eu/privkey.pem;
        include snippets/ssl-params.conf;

        server_name server1.eu;
        root /var/www/server1.eu/webroot;
        index index.php index.html index.htm ;

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
            include fastcgi.conf;
            fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        }
}

and

server {
    listen 80;
    listen [::]:80;
    server_name server2.eu www.server2.eu test.server2.eu mail.server2.eu;
    return 301 https://$server_name$request_uri;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/server2.eu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/server2.eu/privkey.pem;
        include snippets/ssl-params.conf;
        server_name www.server2.eu;
        return 301 https://server2.eu$request_uri;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/server2.eu/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/server2.eu/privkey.pem;
    include snippets/ssl-params.conf;
    server_name server2.eu test.server2.eu mail.server2.eu;
    root /var/www/server2.eu/webroot;
    index index.php index.html index.htm ;

        location / {
            try_files $uri $uri/ /index.php?page=$uri;
        }

        location ~ \.php$ {
            include fastcgi.conf;
            fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        }
}

nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 2048;
    multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    #   keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip             on;
    gzip_comp_level  2;
    gzip_min_length  1000;
    gzip_proxied     expired no-cache no-store private auth;
    gzip_types       text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    client_body_buffer_size 10K;
    client_header_buffer_size 1k;
    client_max_body_size 100m;
    large_client_header_buffers 4 8k;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
    fastcgi_read_timeout 500; #gateway probleem
    client_body_timeout 12;
    client_header_timeout 12;
    keepalive_timeout 25;
    send_timeout 10;
}

A part of the nginx error.log before changing settings in /etc/php/7.2/fpm/pool.d/www.conf:

2018/08/30 16:25:27 [error] 29228#29228: *76 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 2a02:a440:91e3:1:4481:654b:a3e8:9617, server: server1.eu, request: "GET /images/klanten1/JHoogeveen.gif HTTP/2.0", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "server1.eu", referrer: "https://server1.eu/portfolio-2"

Messages from the php7.2-fpm.log before changing settings in /etc/php/7.2/fpm/pool.d/www.conf (there are a lot similar lines)

[30-Aug-2018 16:16:08] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[30-Aug-2018 16:16:27] WARNING: [pool www] child 29026, script '/var/www/server1.eu/webroot/index.php' (request: "GET /index.php") execution timed out (22.937711 sec), terminating
[30-Aug-2018 16:16:27] WARNING: [pool www] child 29245 exited on signal 15 (SIGTERM) after 20.490546 seconds from start
[30-Aug-2018 16:16:27] NOTICE: [pool www] child 29263 started

Below is the timeline of HTTP requests and replies before changing settings in /etc/php/7.2/fpm/pool.d/www.conf.

GET https://server1.eu/portfolio-2 [HTTP/2.0 200 OK 132ms]
GET https://server1.eu/templates/purity_iii/css/bootstrap.css [HTTP/2.0 200 OK 40ms]
GET https://server1.eu/templates/system/css/system.css [HTTP/2.0 200 OK 50ms]
GET https://server1.eu/templates/purity_iii/css/template.css [HTTP/2.0 200 OK 50ms]
GET https://server1.eu/templates/purity_iii/fonts/font-awesome/css/font-awesome.min.css [HTTP/2.0 200 OK 50ms]
GET https://server1.eu/templates/purity_iii/css/layouts/corporate.css [HTTP/2.0 200 OK 50ms]
GET https://server1.eu/media/jui/js/jquery.min.js?48b6d1b3850bca834b403c58682b4579 [HTTP/2.0 200 OK 60ms]
GET https://server1.eu/media/jui/js/jquery-noconflict.js?48b6d1b3850bca834b403c58682b4579 [HTTP/2.0 200 OK 60ms]
GET https://server1.eu/media/jui/js/jquery-migrate.min.js?48b6d1b3850bca834b403c58682b4579 [HTTP/2.0 200 OK 60ms]
GET https://server1.eu/media/system/js/caption.js?48b6d1b3850bca834b403c58682b4579 [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/plugins/system/t3/base-bs3/bootstrap/js/bootstrap.js? 8b6d1b3850bca834b403c58682b4579 [HTTP/2.0 200 OK 80ms]
GET https://server1.eu/plugins/system/t3/base-bs3/js/jquery.tap.min.js [HTTP/2.0 200 OK 80ms]
GET https://server1.eu/plugins/system/t3/base-bs3/js/script.js [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/plugins/system/t3/base-bs3/js/menu.js [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/templates/purity_iii/js/script.js [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/plugins/system/t3/base-bs3/js/nav-collapse.js [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/templates/purity_iii/css/custom-server1.css [HTTP/2.0 200 OK 70ms]
GET https://server1.eu/images/klanten1/schipper2.gif [HTTP/2.0 502 Bad Gateway 23988ms]
GET https://server1.eu/images/klanten1/Kuiper.gif [HTTP/2.0 502 Bad Gateway 24038ms]
GET https://server1.eu/images/klanten1/WindMatch.gif [HTTP/2.0 502 Bad Gateway 24008ms]
GET https://server1.eu/images/klanten1/Tuinland.gif [HTTP/2.0 502 Bad Gateway 24018ms]
GET https://server1.eu/images/klanten1/Wezenberg.gif [HTTP/2.0 502 Bad Gateway 24038ms]
GET https://server1.eu/images/klanten1/Morgenster.gif [HTTP/2.0 502 Bad Gateway 23998ms]
GET https://server1.eu/images/klanten1/Harrie-boerhof.gif [HTTP/2.0 502 Bad Gateway 24028ms]
GET https://server1.eu/images/klanten1/Lococensus.gif [HTTP/2.0 502 Bad Gateway 23998ms]
GET https://server1.eu/images/klanten1/JHoogeveen.gif [HTTP/2.0 502 Bad Gateway 23978ms]
GET https://server1.eu/images/klanten1/DeDeur.gif [HTTP/2.0 502 Bad Gateway 23988ms]
GET https://server1.eu/images/klanten1/Runhaar.gif [HTTP/2.0 502 Bad Gateway 23958ms]
GET https://server1.eu/images/klanten1/Schunselaar-schildersbedrijf.gif [HTTP/2.0 502 Bad Gateway 23948ms]
GET https://server1.eu/images/klanten1/Capelle.gif [HTTP/2.0 502 Bad Gateway 23958ms]
GET https://server1.eu/images/klanten1/Distantlake.gif [HTTP/2.0 502 Bad Gateway 24038ms]
GET https://server1.eu/images/klanten1/Eikenaar.gif [HTTP/2.0 502 Bad Gateway 24018ms]
GET https://server1.eu/images/klanten1/FFWD.gif [HTTP/2.0 404 Not Found 26274ms]
GET https://server1.eu/images/klanten1/Veltec.gif [HTTP/2.0 404 Not Found 26791ms]
GET https://server1.eu/images/klanten1/Heutink.gif [HTTP/2.0 404 Not Found 26811ms]
GET https://server1.eu/images/klanten1/Lindeboom.gif [HTTP/2.0 404 Not Found 26777ms]
GET https://server1.eu/images/klanten1/aataxi.gif [HTTP/2.0 404 Not Found 26828ms]
GET https://server1.eu/images/klanten1/Aewind.gif [HTTP/2.0 404 Not Found 26811ms]
GET https://server1.eu/images/klanten1/Praatmaatgroep.gif [HTTP/2.0 404 Not Found 26800ms]
GET https://server1.eu/media/system/css/system.css [HTTP/2.0 200 OK 20ms]
JQMIGRATE: Migrate is installed, version 1.4.1 jquery-migrate.min.js:2:542
GET https://server1.eu/images/logo.gif [HTTP/2.0 200 OK 20ms]
GET https://server1.eu/images/reclame-en-communicatie.gif [HTTP/2.0 200 OK 20ms]
GET https://server1.eu/fonts/opensans-regular-webfont.woff [HTTP/2.0 200 OK 40ms]
GET https://server1.eu/templates/purity_iii/fonts/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0 [HTTP/2.0 200 OK 70ms]

Note: comparing with the same page on the [old server][3], who has a pm.max_children setting of 5, there is still a long loading time, 8,4 seconds versus 3,16 seconds. Below is the timeline of HTTP requests again:

200 GET portfolio-2 server1.eu document html 4,16 KB 10,84 KB → 267 ms
200 GET custom-server1.css server1.eu stylesheet css 4,09 KB 16,65 KB → 70 ms
404 GET schipper2.gif server1.eu img html 3,26 KB 7,96 KB → 5901 ms
404 GET Kuiper.gif server1.eu img html 3,26 KB 7,96 KB → 7031 ms
404 GET WindMatch.gif server1.eu img html 3,26 KB 7,96 KB→ 5190 ms
404 GET Tuinland.gif server1.eu img html 3,26 KB 7,96 KB → 6741 ms
404 GET Wezenberg.gif server1.eu img html 3,26 KB 7,96 KB → 4910 ms
404 GET Morgenster.gif server1.eu img html 3,26 KB 7,96 KB → 6571 ms
404 GET Harrie-boerhof.gif server1.eu img html 3,26 KB 7,96 KB → 4820 ms
404 GET Lococensus.gif server1.eu img html 3,26 KB 7,96 KB → 4980 ms
200 GET bootstrap.css server1.eu stylesheet css 26,13 KB 150,67 KB → 40 ms
200 GET system.css server1.eu stylesheet css 1,16 KB 894 B → 40 ms
200 GET template.css server1.eu stylesheet css 14,95 KB 70,55 KB → 40 ms
200 GET font-awesome.min.css server1.eu stylesheet css 7,90 KB 30,27 KB → 50 ms
200 GET corporate.css server1.eu stylesheet css 1,02 KB 752 B → 50 ms
200 GET jquery.min.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 37,40 KB 94,89 KB → 60 ms
200 GET jquery-noconflict.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 328 B 21 B → 70 ms
200 GET jquery-migrate.min.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 4,42 KB 9,82 KB → 70 ms
200 GET caption.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 800 B 491 B → 70 ms
200 GET bootstrap.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 17,01 KB 67,34 KB → 70 ms
200 GET jquery.tap.min.js server1.eu script js 1,17 KB 1,84 KB → 70 ms
200 GET script.js server1.eu script js 2,66 KB 6,26 KB → 70 ms
200 GET menu.js server1.eu script js 4,96 KB 16,48 KB → 70 ms
200 GET script.js server1.eu script js 1,50 KB 2,82 KB → 70 ms
200 GET nav-collapse.js server1.eu script js 1,81 KB 4,53 KB → 70 ms
404 GET JHoogeveen.gif server1.eu img html 3,26 KB 7,96 KB → 7141 ms
404 GET DeDeur.gif server1.eu img html 3,26 KB 7,96 KB → 6401 ms
404 GET Runhaar.gif server1.eu img html 3,26 KB 7,96 KB → 6861 ms
404 GET Schunselaar-schildersbedrijf.gif server1.eu img html 3,26 KB 7,96 KB → 7421 ms 
404 GET Capelle.gif server1.eu img html 3,26 KB 7,96 KB → 7171 ms
404 GET Distantlake.gif server1.eu img html 3,26 KB 7,96 KB → 7251 ms 
404 GET Eikenaar.gif server1.eu img html 3,26 KB 7,96 KB → 7191 ms
404 GET FFWD.gif server1.eu img html 3,26 KB 7,96 KB → 7141 ms 
404 GET Veltec.gif server1.eu img html 3,26 KB 7,96 KB → 7551 ms
404 GET Heutink.gif server1.eu img html 3,26 KB 7,96 KB → 7051 ms
404 GET Lindeboom.gif server1.eu img html 3,26 KB 7,96 KB → 7311 ms
404 GET aataxi.gif server1.eu img html 3,26 KB 7,96 KB → 7561 ms
404 GET Aewind.gif server1.eu img html 3,26 KB 7,96 KB → 7631 ms
404 GET Praatmaatgroep.gif server1.eu img html 3,26 KB 7,96 KB → 7591 ms
200 GET system.css server1.eu stylesheet css 845 B 1,41 KB → 10 ms
200 GET logo.gif server1.eu img gif 6,17 KB 5,88 KB → 20 ms
200 GET reclame-en-communicatie.gif server1.eu img gif 9,54 KB 9,25 KB → 20 ms
200 GET opensans-regular-webfont.woff server1.eu font font-woff 24,45 KB 24,15 KB → 40 ms
200 GET fontawesome-webfont.woff2?v=4.7.0 server1.eu font octet-stream 75,66 KB 75,35 KB → 60 ms
200 GET js?id=UA-41464374-1 www.googletagmanager.com script js 28,01 KB 76,92 KB → 50 ms
200 GET analytics.js www.google-analytics.com script js 16,29 KB 38,76 KB → 20 ms
200 GET collect?v=1&_v=j69&a=1138059620&t=pageview&_s=1&dl=https://server1.eu/portfolio-2&ul=nl&de=UTF-8&dt=Portfolio-2&sd=24-bit&sr=1600x1200&vp=1583x1125&je=0&fl=31.0 r0&_u=AACAAUAB~&jid=442053766&gjid=162768711&cid=1071791154.1525078778&tid=UA-41464374-1&_gid=1927096468.1537349155&_r=1&gtm=u9c&z=1503882568
www.google-analytics.com img gif 444 B 35 B

The timeline of HTTP request of the old server:

200 GET portfolio-2 server1.eu document html 4,22 KB 10,83 KB → 230 ms 
200 GET bootstrap.css server1.eu stylesheet css 26,18 KB 150,67 KB → 46 ms 
200 GET system.css server1.eu stylesheet css 759 B 894 B → 107 ms 
200 GET template.css server1.eu stylesheet css 15,01 KB 70,55 KB → 119 ms 
200 GET font-awesome.min.css server1.eu stylesheet css 7,95 KB 30,27 KB → 111 ms 
200 GET corporate.css server1.eu stylesheet css 592 B 752 B → 112 ms 
200 GET jquery.min.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 37,46 KB 94,89 KB → 138 ms 
200 GET jquery-noconflict.js?6d1b3850bca834b403c58682b4579 server1.eu script js 393 B 21 B → 51 ms 
200 GET jquery-migrate.min.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 4,48 KB 9,82 KB → 72 ms 
200 GET caption.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 688 B 491 B → 72 ms 
200 GET bootstrap.js?48b6d1b3850bca834b403c58682b4579 server1.eu script js 17,07 KB 67,34 KB → 93 ms 
200 GET jquery.tap.min.js server1.eu script js 1,23    1,84 KB → 86 ms 
200 GET script.js server1.eu script js 2,72 KB 6,26 KB → 150 ms
200 GET menu.js server1.eu script js 5,02 KB 16,48 KB → 141 ms 
200 GET script.js server1.eu script js 1,56 KB 2,82 KB → 142 ms 
200 GET nav-apse.js server1.eu script js 1,87 KB 4,53 KB → 144 ms 
200 GET custom-server1.css server1.eu stylesheet css 4,15 KB 16,65 KB → 146 ms 
404 GET schipper2.gif server1.eu img html 327 B 162 B → 157 ms 
404 GET Kuiper.gif  server1.eu img html 327 B 162 B → 158 ms 
404 GET WindMatch.gif server1.eu img html 327 B 162 B → 149 ms 
404 GET Tuinland.gif server1.eu img html 327 B 162 B → 151 ms 
404 GET Wezenberg.gif server1.eu img html 327 B 162 B → 152 ms 
404 GET Morgenster.gif server1.eu img html 327 B 162 B → 150 ms 
404 GET Harrie-boerhof.gif server1.eu img html 327 B 162 B → 152 ms 
404 GET Lococensus.gif server1.eu img html 327 B 162 B → 152 ms 
404 GET JHoogeveen.gif server1.eu img html 327 B 162 B → 151 ms 
404 GET DeDeur.gif server1.eu img html 327 B 162 B → 154 ms 
404 GET Runhaar.gif server1.eu img html 327 B 162 B → 154 ms 
404 GET Schunselaar-schildersbedrijf.gif server1.eu img html 327 B 162 B → 154 ms 
404 GET Capelle.gif server1.eu img html 327 B 162 B → 157 ms 
404  GET Eikenaar.gif server1.eu img html 327   162 B → 158 ms 
404 GET FFWD.gif server1.eu img html 327 B 162 B → 161 ms 
404 GET Veltec.gif server1.eu img html 327 B 162 B → 166 ms 
404 GET Heutink.gif server1.eu img html 327 B 162 B → 166 ms 
404 GET Lindeboom.gif server1.eu img html 327 B 162 B → 166 ms 
404 GET Distantlake.gif server1.eu img html 327 B 162 B → 158 ms 
404 GET ataxi.gif uyk.eu img html 327 B 162 B → 160 ms 
404 GET Aewind.gif server1.eu img html 327 B 162   → 161 ms 
404 GET Praatmaatgroep.gif server1.eu img html 327 B 162 B → 163 ms 
200 GET system.css server1.eu stylesheet css 903 B 1,41 KB → 12 ms 
200 GET logo.gif server1.eu img gif 6,20 KB 5,88 KB → 14 ms 
404 GET schipper2.gif server1.eu img html 327 B 162 B → 13 ms 
404 GET Kuiper.gif server1.eu img html 327 B 162 B → 15 ms 
404 GET WindMatch.gif server1.eu img html 327 B 162 B → 16 ms 
404 GET Tuinland.gif server1.eu img html 327 B 162 B → 18 ms 
404 GET Wezenberg.gif server1.eu img html 327 B 162 B → 20 ms 
404 GET Morgenster.gif server1.eu img html 327 B 162 B → 23 ms 
404 GET Harrie-boerhof.gif server1.eu img html 327 B 162 B → 25 ms 
404 GET Lococensus.gif server1.eu img html 327 B 162 B → 26 ms 
404 GET JHoogeveen.gif server1.eu img html 327 B 162 B → 29 ms 
404 GET DeDeur.gif server1.eu img html 327 B 162 B → 30 ms 
404 GET Runhaar.gif server1.eu img html 327 B 162 B → 33 ms 
404 GET Schunselaar-schildersbedrijf.gif server1.eu img html 327 B 162 B → 35 ms 
404 GET Capelle.gif server1.eu img html 327 B 162 B → 37 ms 
404 GET Distantlake.gif server1.eu img html 327 B 162 B → 38 ms 
404 GET Eikenaar.gif server1.eu img html 327 B 162 B → 40 ms 
404 GET FFWD.gif server1.eu img html 327 B 162 B → 42 ms 
404 GET Veltec.gif server1.eu img html 327 B 162 B → 45 ms 
404 GET Heutink.gif server1.eu img html 327 B 162 B → 46 ms 
404 GET Lindeboom.gif server1.eu img html 327 B 162 B → 49 ms 
404 GET aataxi.gif server1.eu img html 327 B 162 B →   160 ms 
404 GET Aewind.gif server1.eu img html 327 B 162 B → 10 ms 
404 GET Praatmaatgroep.gif server1.eu img html 327 B 162 B → 13 ms 
200 GET reclame-en-communicatie.gif server1.eu img gif 9,57 KB 9,25 KB → 18 ms 
200 GET opensans-regular-webfont.woff server1.eu font octet-stream 24,44   24,15 KB → 43 ms 
200 GET fontawesome-webfont.woff2?v=4.7.0 server1.eu font octet-stream 75,64 KB 75,35 KB → 53 ms 
200 GET js?id=UA-41464374-1 www.googletagmanager.com script js 28,01 KB 76,92 KB → 179 ms 
200 GET analytics.js www.google-analytics.com script js 16,29 KB 38,76 KB → 15 ms 
200 GET collect?v=1&_v=j69&a=1196607213&t=pageview&_s=1&dl=https://server1.eu/portfolio-2&ul=nl&de=UTF-8&dt=Portfolio-2&sd=24-bit&sr=1600x1200&vp=1583x1125&je=0&fl=31.0 r0&_u=AACAAUAB~&jid=593009893&gjid=1416231654&cid=1071791154.1525078778&tid=UA-41464374-1&_gid=1927096468.1537349155&_r=1&gtm=u9c&z=1966144014
www.google-analytics.com img gif 444 B 35 B

Ser answered 17/9, 2018 at 6:47 Comment(9)

Try fixing the pm.max_children php fpm issue. 502 errors should go away if all requests are reaching the server. – Peag 17/9, 2018 at 13:22

For response time, if you have some measurements in place, we can see what exactly is going wrong. – Peag 17/9, 2018 at 13:46

Thanks, measurements are added. – Ser 21/9, 2018 at 9:9

I'm not sure this question makes any sense — you shouldn't have different 200 vs. 404 replies depending on whether or not IPv6 is enabled. Do you have any other server configurations over the same ports? What's the result of find /etc/nginx/{conf.d,sites-enabled}? What about find /etc/nginx/{conf.d,sites-enabled} | xargs fgrep listen? Have you tried removing the non-IPv6 listen directive? – Tevere 21/9, 2018 at 21:1

The difference between 200 and 404 reply is the extra handling of 404 by the php app. I've edited the question with the result of "find /etc/nginx/{conf.d,sites-enabled}" and "find /etc/nginx/{conf.d,sites-enabled} | xargs fgrep listen". If I remove the non-IPv6 listen directive, the browser warns that there is a certificate mismatch SSL_ERROR_BAD_CERT_DOMAIN certificate only for fellowshipmedia.eu, mail.fellowshipmedia.eu, test.fellowshipmedia.eu, www.fellowshipmedia.eu, which is another domain that is hosted on the same server – Ser 22/9, 2018 at 9:42

Having followed the earlier incantation of this question, it seems clear that there are a number of differences in the two servers, and I am not sure why you are convinced it has to do with ipv6/4 rather than other configuration changes. Maybe stating the obvious, but all of the files taking a long time say "96 KB". In the earlier question there was a comment on speeding up the 404 processing. Did you try that? – Munro 23/9, 2018 at 3:35

Yes, I am convinced it is a DNS issue because when I I disable IPv4 so that only IPv6 is enabled, there is a certificate mismatch SSL_ERROR_BAD_CERT_DOMAIN. We could solve symptoms on a higher level by changing PHP configuration and speeding up 404 processing. Yes, I've tried that. Removing file_get_contents already does the trick but does not solve the lower level problem. – Ser 23/9, 2018 at 11:0

TBH, the question is so long and has so much seemingly unrelated stuff in it, I don't even understand what's being asked. What exact problem are you experiencing? Have you tried reproducing it with curl alone? – Tevere 23/9, 2018 at 21:51

There's so much stuff because it is not yet clear where the slow response comes from. The first alinea states the problem and this question: "is it a DNS problem that causes these delays and 502 errors and what should I change in the setup?" Curl reproduces the same slowness. – Ser 25/9, 2018 at 7:14

The question has so much stuff, it's not even clear what's being asked — all those non-server-log 404 errors don't mean much to most readers, and, certainly, I've never heard of the mere presence of IPv6 having any sort of effects on image requests suddenly returning 404 errors.

You've already provided find /etc/nginx/{conf.d,sites-enabled} and find /etc/nginx/{conf.d,sites-enabled} | xargs fgrep listen, and there's nothing out-of-the-ordinary there — it seems that every non-IPv4 listen is accompanied by an IPv6 listen. http://nginx.org/r/listen.

The next step, IMHO, would be to reproduce the error directly with curl alone, including using some combination of the -v, -4 and -6 flags to see what's going on. Make absolute sure you're doing it from the same client host where you're actually experiencing the errors you're trying to correct; this whole issue might as well stem from something being amiss on the client side.

Another useful feature of curl would be to use the domain-mapping if you think your issues are related to DNS. You can already see which IP address the request would go to if you use the -v option with curl (which may reveal the stale DNS easily, unless it's only stale within your browser); the next step is to possibly override the IP address with the --resolve option, e.g., --resolve test.vuyk.eu:443:2a03:b0c0:0:1010::190:6001 or some such.

Finally, if you're still experiencing delay and failure only over IPv6 (-6) and not via IPv4 (-4), then the issue might be related to the IPv6 connection on the client; specifically, if your connection goes through a tunnel or 6rd, then perhaps MTU discovery is broken along the path; on Linux, you could try using tracepath to troubleshoot, it prints pmtu values along the path.

FWIIW, I've tried accessing your site via an IPv6 native connection via TMo US, with MTU of 1500 for IPv6 (they actually tunnel IPv4 through IPv6, so, IPv4 MTU is 1472 on T-Mo US, from what I understand), and I couldn't see any obvious issues (and, as far as I see, you do currently have IPv6 records published for test.vuyk.eu). Perhaps the whole issue is due to stale DNS cache on the client side in your setup? What are you seeing in server logs for all those 404 errors that you see in the client?!

Tevere answered 23/9, 2018 at 22:43 Comment(16)

Thanks for the elaborate answer. There's so much stuff because it is not yet clear where the slow response comes from. The 404's are deliberately caused by missing images, not IPv6 presence. The first alinea states the problem and this question: "is it a DNS problem that causes these delays and 502 errors and what should I change in the setup?" – Ser 24/9, 2018 at 8:14

When I try 'normal' curl, this is also very slow. I have no experience with curl domain mapping, -4 and -6 flags, and testing IPv6 connection on the client. Could you give an example of how to test this? About stale DNS cache on the client side, I use a Digitalocean VPS, I thought if nothing shows up, perhaps their IPv6 setup could be a cause. The server syslog doesn't record anything, nginx and php logs do (see above). – Ser 24/9, 2018 at 8:14

@C.A.Vuyk, you don't really need to do the domain mapping, just use curl -4 to limit requests to IPv4 and curl -6 to limit it to IPv6; see if one or the other times out as appropriate. – Tevere 24/9, 2018 at 19:43

Can you explain why the 404 errors deliberately caused by missing images? I don't think it makes any sense. Besides, based on the filenames, I don't even understand why you're trying to serve static images through an upstream, and not directly with nginx. This question sounds like the perfect example of the XY Problem. – Tevere 24/9, 2018 at 22:23

No, it's not an XY. Accidently I had this page where all the images were broken links and noticed the slow loading. So I figured there should be something wrong with the server setup. I don't understand your remark about upstream, the images are served directly through nginx. – Ser 25/9, 2018 at 6:40

You think the question is not clear, so I edited the question, hoping this makes it more distinct. – Ser 25/9, 2018 at 7:44

@C.A.Vuyk, the whole question just too convoluted and has too many unrelated claims and issues; the original claim is that of DNS and IPv6 issues, yet now there are claims that access via "IPv4 definitely is troubled" as well — so, which one is it?! Getting delays and 502 errors on non-existing images with .gif filenames means you're overloading your PHP at any time an image isn't found by nginx directly, and clearly that has nothing to do with either DNS or IPv4 or IPv6. It's still not very clear what you're even asking, TBH. What are the config differences between old and new server? – Tevere 26/9, 2018 at 4:19

Explained earlier that the problem isn't clear yet, that's why the many (maybe?) unrelated claims and issues. There is seemingly no reason for the overloading. I'll try to find any server differences and will edit the question when I find some. – Ser 26/9, 2018 at 6:3

@C.A.Vuyk, I think the problems should be troubleshooted separately. IPv6 has absolutely zero relation to PHP's pm.max_children, and the number of variables in the question is just through the roof. Under a good-enough stress test, it's easy to bring down any server that does any level of a non-trivial processing for each request. This then becomes the XY Problem, as the issue is with the architecture (e.g., having a dynamic site for what should be static content, and/or it should be heavily cached and/or with a limited number of unique entry points to avoid the DoS). – Tevere 26/9, 2018 at 6:52

So, you think I should split this up in separate questions then? That may be better. – Ser 26/9, 2018 at 7:33

@C.A.Vuyk, TBH, I think you should first try to solve it from scratch, and only ask questions if you actually get stuck on something for real, and with a minimally reproducible test case for each issue. – Tevere 26/9, 2018 at 7:38

Edited question: added curl -4 and -6. I'm definitely stuck on the question why the difference in handling of this testpage by the two servers. Trying to solve that I ran into the dns problem which I also couldn't figure out. So I think I'll launch that first as a new question as minimal as possible. Thanks for the help so far. – Ser 26/9, 2018 at 12:57

One difference in servers is the old has http1.1 and the new http2. Disabling http2 solves the extreme long loading and 502 errors. Still loading time for the page remains longer than old server (6.40 vs 3.18 sec) – Ser 27/9, 2018 at 9:32

Are you still serving your 404 page using a php script which makes another network request to your own server each time instead saving your custom page as a static file and letting Nginx serve it? Cos trust me, thats the root of all your head scratching. Fix that and watch 6.4/3.1 secs become <1s and no more 502s – Dowzall 28/9, 2018 at 13:34

@C.A.Vuyk, http2 is supposed to make it possible to have more simultaneous requests via a single connection, so, that may be the reason why you had to adjust the number of concurrent php processes. – Tevere 28/9, 2018 at 20:20

That makes sense. First I will ask a more specific question as you suggested: #52586883 – Ser 1/10, 2018 at 7:30

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags