Why my nginx conf file redirects subdomains to main domain?

I have removed all files from /etc/nginx/sites-enabled/ directory.

I have also removed all files from /etc/nginx/sites-available/ directory.

I only have one file in /etc/nginx/conf.d/ called my-domain-name.com.conf and it contains:

server {
    listen 80;
    server_name my-domain-name.com www.my-domain-name.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name my-domain-name.com www.my-domain-name.com;

    ssl_certificate /etc/letsencrypt/live/my-domain-name.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my-domain-name.com/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        proxy_pass http://localhost:4000;
    }
}

I proxy traffic to a docker container that listens on port 4000.

It works great for my-domain-name.com and www.my-domain-name.com.

However, it also redirects ALL of my subdomains that have been defined in DNS.

This is not the intended behavior. I only want this file to serve these two domains, not more.

What is wrong here?

Update:

I added another file, called sudomain.my-domain-name.com.conf and I added this configuration inside it:

server {
    listen 80;
    server_name subdomain.my-domain-name.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name subdomain.my-domain-name.com;

    ssl_certificate /etc/letsencrypt/live/my-domain-name.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my-domain-name.com/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        proxy_pass http://localhost:3131;
    }
}

And nginx -t shows success and nginx -s reload is also applied. But again when I go to subdomain.my-domain-name.com, instead of getting my second docker that is running on port 3131, again I'm redirected to my-domain-name.com page.

Please show nginx configuration of your subdomains.

EDIT 1:

Try adding this config file (name it as you wish):

server {
    listen 80;
    server_name my-subdomain-name.my-domain-name.com www.my-subdomain-name.my-domain-name.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    
    server_name my-subdomain-name.my-domain-name.com www.my-subdomain-name.my-domain-name.com;

    ssl_certificate /etc/letsencrypt/live/my-subdomain-name.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my-subdomain-name.com/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
#      You can change port, url if you wish
        proxy_pass http://localhost:4000;
    }
}

EDIT 2:

For example you have this subdomain: test.my-domain.com Then you have to set up your server to serve files from that subdomain. For that, we've to create a nginx config file.

However, it also redirects ALL of my subdomains that have been defined in DNS. [...] This is not the intended behavior. I only want this file to serve these two domains, not more.

If a subdomain resolves to the same IP address as the server hosting the two domains that you actually want to serve, Nginx is going to be forced to deal with those incoming requests.

Why it redirects ALL traffic to my main domain, while it's explicitly being told to only serve my main domain?

This is the default behavior. Nginx does try to route the requests to the appropriate server by using the Host HTTP header, but if there's no match, it routes the traffic to the default server. This seems to be the source of the confusion.

If the Host header field does not match a server name, NGINX Plus routes the request to the default server for the port on which the request arrived. The default server is the first one listed in the nginx.conf file, unless you include the default_server parameter to the listen directive to explicitly designate a server as the default¹.

To actually prevent the server from serving your domain's content unless specifically requested, you could add an actual default server block. You could even return 204 No Content for all requests if you wanted to, although something even slightly more nuanced is probably always preferable.