Nginx try_files doesn't work inside server block

http {
include mime.types;
default_type application/octet-stream;

server {
    root /websites;
    listen 80;
    server_name localhost;

    # don't work
    try_files /logo.png /logo.jpg /error;

    # works
    rewrite ^/e /error;

    # works
    # return 200 "$request_uri Handled by server block";

    location / {
        default_type text/plain;
        return 200 "Root prefix matched";
    }

    location /error {
        default_type text/plain;
        return 404 "Logo not found";
    }
}

I want to know what is the cause of this evaluation, I couldn't find any reliable explanation neither on documentation nor on forums.

By the way I've experimented the following scenario:

• Removed location / {} block and it worked as intended. I know that when the request is made to the server it first evaluated by server block and then matched location blocks. But it seems try_files directive is ignored(WHY?!!). If I'm correct the last argument of try_files directive rewrites the URI so it should behave as rewrite directive. Both rewrite and return directives worked as intended, they evaluated every time irrespective to whether there are location block matches or not.

I researched a lot to find reliable information explaining this situation, but I couldn't find. So I'm asking here for the answer or source about Nginx internals someone who knows.

See how nginx processes a request. But I will add a couple of caveats that specifically address your question and are easily observed but may not be well documented.

You mention rewrite and return directives, but these belong to the ngx_http_rewrite_module which have there own evaluation rules and do not behave the same as the core directives. You are correct that rewrite and return in server context can execute before the location block is selected.

As you have observed (with the exception of the ngx_http_rewrite_module), the server context acts like the default location, that is, if no other location block matches the request. The presence of an explicit location / { ... } block will always take precedence.