Удалить часть пути в proxy_pass

Содержание

Вопрос или проблема
Ответ или решение
Проблема
Текущее состояние конфигурации
Оптимальное решение
Пояснение
Заключение

Вопрос или проблема

Мне нужно избавиться от части squirrelmail/ в пути, который видит пользователь.

Мой .conf:

location / {
    rewrite /squirrelmail/(.*) /$1 last;
    proxy_pass https://internal.domain.tld:8081/squirrelmail/;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Я ожидаю, что мое приложение будет доступно для пользователей по корневому пути /, вместо того чтобы постоянно добавлять squirrelmail/ к пути конечного пользователя.

Таким образом, когда пользователь переходит на https://mail.domain.tld, это правильно проксирует фактическое приложение, расположенное по адресу https://internal.domain.tld:8081/squirrelmail/, без добавления squirrelmail/ к пути пользователя (например, https://mail.domain.tld/squirrelmail/)

UPD:

Без переписывания, после того как пользователь переходит на https://mail.domain.tld, добавляется часть squirrelmail/ к следующим запросам (например, при навигации на другую вкладку, открытии почты и т.д.) приложением, поэтому для пользователя это выглядит как https://mail.domain.tld/squirrelmail/?some=params, но для приложения это теперь https://internal.domain.tld:8081/squirrelmail/squirrelmail/?some=params, что вызывает HTTP 404.

Ответ или решение

Чтобы удалить часть пути squirrelmail/ из URL, видимого пользователю, и корректно настроить проксирование запросов к приложению, вам нужно изменить конфигурацию вашего Nginx. Давайте подробно рассмотрим вашу ситуацию и предложим оптимальное решение.

Проблема

Ваше приложение находится по адресу https://internal.domain.tld:8081/squirrelmail/, и вы хотите сделать его доступным для пользователей на корневом пути (https://mail.domain.tld), исключив лишнюю часть пути, чтобы при навигации не возникали ошибки, связанные с добавлением squirrelmail/ к URL.

Текущее состояние конфигурации

Согласно предоставленной конфигурации:

location / {
    rewrite /squirrelmail/(.*) /$1 last;
    proxy_pass https://internal.domain.tld:8081/squirrelmail/;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Вы используете директиву rewrite, чтобы попытаться убрать squirrelmail/ из URL, но при этом, как вы заметили, происходит конфликт при повторном обращении к приложению, когда оно отсылает запросы с добавленной частью пути.

Оптимальное решение

Для правильного функционирования вам нужно настроить Nginx таким образом, чтобы он корректно обрабатывал пути, передавая их целиком на внутренний сервис. Вот обновленная версия вашей конфигурации:

location / {
    rewrite ^/squirrelmail/(.*)$ /$1 break;  # Удаляем squirrelmail из пути
    proxy_pass https://internal.domain.tld:8081/squirrelmail/;  # Проксируем к внутреннему сервису

    # Добавляем необходимые заголовки
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;

    # Убедитесь, что записи не кэшируются
    proxy_cache off;
}

Пояснение

Использование rewrite: Используйте ^/squirrelmail/(.*)$ в директиве rewrite, чтобы корректно обрабатывать запросы и передавать их без squirrelmail/. Необходимо также использовать break, чтобы прекращать обработку текущего запроса и передавать управление на следующий обработчик, что предотвращает дублирование пути.
proxy_pass: Директива proxy_pass указывает, что все запросы к / (включая все вложенные пути) должны проксироваться на внутренний сервер https://internal.domain.tld:8081/squirrelmail/. Важно оставить /squirrelmail/ в конце, чтобы сервер знал, куда направлять запросы.
Заголовки: Убедитесь, что заголовки X-Forwarded-* остаются, чтобы ваше приложение знало о реальном IP-адресе клиента и корректном хосте.
Кэширование: Отключите кэширование, чтобы избежать возможных проблем с кешированием ответов, особенно если ваше приложение зависит от динамических данных.

Заключение

После внесения этих изменений перезапустите Nginx, чтобы протестировать новую конфигурацию. Теперь пользователи будут видеть ваш сервис по адресу https://mail.domain.tld без дополнительных squirrelmail/ в URL, и приложение не будет сталкиваться с 404 ошибками при навигации по своим внутренним ссылкам.

Если возникнут дополнительные вопросы или потребуется помощь, не стесняйтесь обращаться.