Эсли uri является domaindotcom/me тогда fallback uri будет использовать. Т.е,

энжинкс обработывает как статичный файл, да? Но это не так работает. php-fpm обработывает Этот файл. Как это понять? Я вообще не понял... Просто мозг упал 😄

Что именно не понятно? Есть такой файл - отдаём как статику Нет такого файла - запрос обрабатывает index.php

Да это понятно. Но запрос обрабатывает индекс.пхп через fastcgi т.е php-fpm а не как статичный файл

Ну если бы это было не так, ты бы получил в виде ответа исходный код этого index.php В чём вопрос?

Да, там есть вопрос. Я выделил локация ~ \.php$ для пхп файлов что нужно fastcgi. А на try_files нет fastcgi. Как nginx обрабатывает фаллбек ури even if the fastcgi is not defined inside that location context?

Machine translation? The last try_files parameter is completely different from the others. When try_files fallback is specified as URI, nginx will search most suitable location to handle that URI from the beginning (and even more, the SERVER_REWRITE request processing phase will be fired again). Every other try_files parameter is treated as a filename relative to root, and that file, if exists, will be processed using that location content handler.

did you mean that the fallback uri index.php?$query_string is treated as filename relative to the root, yeah?

It is treated as a completely new URI to evaluate from the beginning. The key sentence was The last try_files parameter is completely different from the others. You can't do something like try_files $uri $uri.php $uri/ =404; The uri.php, even if being an existed file, will be processed according to the location content handler (you call it "location context", ok). But when the very last try_files parameter is an URI pointing to the PHP file, that URI will be processed as a new URI, and another location will be chosen to handle it. Consider it as a jump to another location.

Did you mean by "it is treated as a completely new URI" an rewriting? try_files behaves as rewriter if it has the third parameter? It sets the third parameter's value to the current URI?

Not the third. The last one. It can be second, third, fourth and so on. Did you try to read the documentation? And it isn't work exactly as a rewrite ... last directive. Rewrite made by the try_files directive last parameter (when it is a new URI and not the named location ID) will start from the HTTP_SERVER_REWRITE request processing phase in opposite to the rewrite ... last, which will trigger the HTTP_FIND_CONFIG phase (request processing phases description can be found here).

теперь понятно спасибо большое