NGINX utilizza altri blocchi server come impostazione predefinita

Attualmente sto configurando il mio server nginx e ho riscontrato un problema in cui non riesco a trovare il problema che ho riscontrato, anche dopo ore di ricerca.
Sto eseguendo Debian 9 con PHP 7.2-fpm su NGINX.
Quindi, ho installato i seguenti blocchi server per diversi sottodomini:

sites-enabled
- www.example.com    #this config covers both www.example.com and example.com
- pfa.example.com    #this config covers pfa.example.com

Questi sono i contenuti di questi file (ho rimosso la configurazione predefinita dai siti abilitati, ne ho lasciato un backup nei siti disponibili):
www.example.com

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl http2; # managed by Certbot
    listen [::]:443 ssl http2; # managed by Certbot
    server_name www.example.com;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_dhparam /etc/letsencrypt/live/www.example.com/dh.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/chain.pem;
    resolver 8.8.8.8;

    root /var/www/www.example.com/html/;
    index index.php index.html index.htm;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header x-xss-protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;

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

Chiamare entrambi example.come www.example.comfunziona perfettamente (reindirizza a https e mostra il contenuto di /var/www/www.example.com/html/).
Questa è la configurazione di pfa.example.com:

server {
    listen 80 http2;
    listen [::]:80 http2;
    server_name pfa.example.com;
    return 301 https://pfa.example.com$request_uri;
}
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name pfa.example.com;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/pfa.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/pfa.example.com/privkey.pem; # managed by Certbot
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_dhparam /etc/letsencrypt/live/pfa.example.com/dh.pem;

    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/pfa.example.com/chain.pem;
    resolver 8.8.8.8;

    root /var/www/html/;
    index index.php index.html index.htm;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header x-xss-protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/run/php/php7.2-fpm.sock;
    }
}

Ho configurato le dh.pemchiavi a 2048 bit tramite openssl per entrambi i domini.
Chiamare questa pagina funziona anche come previsto.

Ecco il mio problema: quando si chiama una pagina casuale come abc.example.com, utilizzerà la configurazione di pfa.example.comcome configurazione "predefinita". Ho controllato le dichiarazioni del server un milione di volte, non riesco a capire come il blocco del server pfa.example.compossa essere confuso come un tuttofare (funziona anche per sdfsdfjikdsfjsdfhjsd.example.com). Questo non è solo fastidioso per i potenziali visitatori, ma anche per me, poiché, quando si chiama una pagina come https://abc.example.com, tenterà di utilizzare la configurazione ssl per pfa.example.com, causando un errore.
nginx -tnon restituisce errori.
Dov'è l'errore di sintassi che ho supervisionato?

EDIT: ho eliminato la configurazione predefinita del vhost perché consentirebbe pfa.example.comcomunque il passaggio del traffico 443 . Dal momento che ho un backup della configurazione predefinita, posso facilmente aggiungerlo nuovamente. In seguito avrei comunque bisogno di una soluzione per restituire un errore 404 sul traffico ssl per sottodomini inesistenti. Qualsiasi aiuto è apprezzato.

C'è sempre un vhost predefinito in nginx. Può essere esplicitamente configurato usando l' defaultopzione per listendirettiva. Se omesso, nginx utilizzerà il primo vhost dichiarato mentre analizza la sua configurazione come predefinita. Quindi sembra che pfa.example.com si sia verificato per primo.

È possibile visualizzare l'ordine effettivo nella configurazione finale unita emettendo nginx -T.