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

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

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/ из 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;
}

Пояснение

1. Использование rewrite: Используйте ^/squirrelmail/(.*)$ в директиве rewrite, чтобы корректно обрабатывать запросы и передавать их без squirrelmail/. Необходимо также использовать break, чтобы прекращать обработку текущего запроса и передавать управление на следующий обработчик, что предотвращает дублирование пути.

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

3. Заголовки: Убедитесь, что заголовки X-Forwarded-* остаются, чтобы ваше приложение знало о реальном IP-адресе клиента и корректном хосте.

4. Кэширование: Отключите кэширование, чтобы избежать возможных проблем с кешированием ответов, особенно если ваше приложение зависит от динамических данных.

Заключение

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

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