Почему nginx «return 301» и ”try_files“ попадают в бесконечный цикл

Почему nginx «return 301» и ”try_files“ попадают в бесконечный цикл

мой код конфигурации:

index index.html index.php;
location / {
    if ($uri = '/a/') {
        return 301 https://example.com/a;
    }
    try_files $uri $uri/ =404; 
}

Если URL-адрес — /a/, 301 к /a, ​​то try_filesчасть, добавьте /в /aконец, станет /a/.

Следующий шаг, я думаю, это попытка indexопределения, превращения /a/index.htmlв файл и достижения его.

Но на самом деле, он попытался /a/, и выпрыгнул location, а затем снова вошел location, в if ($uri = '/a/') { ... }.

Затем бесконечный цикл.

Да я просто запутался.


Что я хочу сделать, так это

  1. Если запрос example.com/a/, перейти к example.com/a, затем к 2
  2. Если запрос example.com/a, показать example.com/a/index.html(но URL-адрес example.com/a).

Кто-нибудь может мне помочь в этом?

решение1

Он делает именно то, для чего предназначен.

Вы никогда не сможете достичь, /a/index.htmlпотому что вы продолжаете перенаправляться обратно, /aпрежде чем это может произойти. Когда nginx обрабатывает это, он видит каталог в файловой системе и автоматически перенаправляет (правильно) в /a/.

Вам следует удалить это ненадлежащее перенаправление.

решение2

Добро пожаловать в ServerFault. Вы можете сделать то, что указано в OP, с помощью следующего кода...

location / {
    if ($uri = '/a/') {
        return 301 https://example.com/a;
    }
    try_files $uri $uri/index.html =404; 
}

Пожалуйста, ознакомьтесь с соответствующим вопросом и принятым ответом по адресуУдаление завершающего слеша из URL с помощью nginx.

По сути, нам не нужно полагаться на кого-то index, а скорее обслуживать index.htmlнапрямую, когда example.com/aэто требуется.

Связанный контент