.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$

Спасибо всем, кто откликнулся. Получилось решить данную задачу. Этот комментарий с решением оставляю, может быть кому-то пригодится.

Для настройки редиректа изображений с одного домена на другой в первую очередь следует понять, кто обрабатывает статические файлы (изображения и т.п.). Если ngnix, то правила в .htaccess не будут работать.

Чтобы настроить редирект нужно прописать следующие строчки в конфигурационном файле ngnix конкретного домена (с которого нужен редирект):

location /dir/ {
    return 301 https://domain.com$request_uri;
}

где:

• /dir/ — папка изображений в которой находятся изображения (в том числе будет работать и с вложенными подпапками, то есть не нужно перечислять все вложенные подпапки)
• domain.com — домен на который нужен редирект

По поводу использования rewrite или return. Вот что пишут на просторах Интернета:

return предпочтительнее rewrite потому, что rewrite требует интерпретации регулярного выражения — ^(. *)$ — и создания пользовательской переменной ($1) , что на самом деле эквивалентно встроенной переменной $request_uri

Я использовал конструкцию «return 301», благодаря которой нет никаких промежуточных редиректов.

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

Модуль ngx_http_rewrite_module

Директивы      break      if      return      rewrite      rewrite_log      set      uninitialized_variable_warn Внутреннее устройство

Модуль ngx_http_rewrite_module позволяет изменять URI запроса с помощью регулярных выражений PCRE, делать перенаправления и выбирать конфигурацию по условию.

Директивы break, if, return, rewrite и set обрабатываются в следующем порядке:

• последовательно выполняются директивы этого модуля, описанные на уровне server;
• в цикле:
  • ищется location по URI запроса;
  • последовательно выполняются директивы этого модуля, описанные в найденном location;
  • цикл повторяется, если URI запроса изменялся, но не более 10 раз.

Директивы

Синтаксис:	break;
Умолчание:	—
Контекст:	server, location, if

Завершает обработку текущего набора директив модуля ngx_http_rewrite_module.

Если директива указана внутри location, дальнейшая обработка запроса продолжается в этом location.

Пример:

if ($slow) {
    limit_rate 10k;
    break;
}

Синтаксис:	if (условие) { ... }
Умолчание:	—
Контекст:	server, location

Проверяется указанное условие. Если оно истинно, то выполняются указанные в фигурных скобках директивы этого модуля и запросу назначается конфигурация, указанная внутри директивы

if. Конфигурации внутри директив if наследуются с предыдущего уровня конфигурации.

В качестве условия могут быть заданы:

• имя переменной; ложными значениями переменной являются пустая строка или “0”;

  До версии 1.0.1 ложным значением также являлась любая строка, начинающаяся на “0”.

• сравнение переменной со строкой с помощью операторов “=” и “!=”;
• соответствие переменной регулярному выражению с учётом регистра символов — “~” и без него — “~*”. В регулярных выражениях можно использовать выделения, которые затем доступны в виде переменных $1..$9. Также можно использовать отрицательные операторы “!~” и “!~*”. Если в регулярном выражении встречаются символы “ }” или “;”, то всё выражение следует заключить в одинарные или двойные кавычки.
• проверка существования файла с помощью операторов “-f” и “!-f”;
• проверка существования каталога с помощью операторов “-d” и “!-d”;
• проверка существования файла, каталога или символической ссылки с помощью операторов “-e” и “!-e”;
• проверка исполняемости файла с помощью операторов “-x” и “!-x”. ;]+)(?:;|$)») { set $id $1; } if ($request_method = POST) { return 405; } if ($slow) { limit_rate 10k; } if ($invalid_referer) { return 403; }

  Значение встроенной переменной $invalid_referer задаётся директивой valid_referers.

  Синтаксис:	return код [текст]; return код URL; return URL;
  Умолчание:	—
  Контекст:	server, location, if

  Завершает обработку и возвращает клиенту указанный код. Нестандартный код 444 закрывает соединение без передачи заголовка ответа.

  Начиная с версии 0.8.42 можно задать либо URL перенаправления (для кодов 301, 302, 303, 307 и 308) либо

  текст тела ответа (для остальных кодов). В тексте тела ответа и URL перенаправления можно использовать переменные. Как частный случай, URL перенаправления может быть задан как URI, локальный для данного сервера, при этом полный URL перенаправления формируется согласно схеме запроса ($scheme) и директивам server_name_in_redirect и port_in_redirect.

  Кроме того, в качестве единственного параметра можно указать URL для временного перенаправления с кодом 302. Такой параметр должен начинаться со строк “http://”, “https://” или “$scheme”. В URL можно использовать переменные.

  До версии 0.7.51 можно было возвращать только следующие коды: 204, 400, 402 — 406, 408, 410, 411, 413, 416 и 500 — 504.

  До версий 1.1.16 и 1.0.13 код 307 не обрабатывался как перенаправление.

  До версии 1.13.0 код 308 не обрабатывался как перенаправление.

  См. также директиву error_page.

  Синтаксис:	rewrite regex замена [флаг];
  Умолчание:	—
  Контекст:	server, location, if

  Если указанное регулярное выражение соответствует URI запроса, URI изменяется в соответствии со строкой замены. Директивы

  rewrite выполняются последовательно, в порядке их следования в конфигурационном файле. С помощью флагов можно прекратить дальнейшую обработку директив. Если строка замены начинается с “http://”, “https://” или “$scheme”, то обработка завершается и клиенту возвращается перенаправление.

  Необязательный параметр флаг может быть одним из:

  last

  завершает обработку текущего набора директив модуля ngx_http_rewrite_module, после чего ищется новый location, соответствующий изменённому URI;

  break

  завершает обработку текущего набора директив модуля ngx_http_rewrite_module аналогично директиве break;

  redirect

  возвращает временное перенаправление с кодом 302; используется, если заменяющая строка не начинается с “

  http://”, “https://” или “$scheme”;

  permanent

  возвращает постоянное перенаправление с кодом 301.

  Полный URL перенаправлений формируется согласно схеме запроса ($scheme) и директив server_name_in_redirect и port_in_redirect. /users/(.*)$ /show?user=$1? last;

  Если в регулярном выражении встречаются символы “}” или “;”, то всё выражение следует заключить в одинарные или двойные кавычки.

  Синтаксис:	rewrite_log on | off;
  Умолчание:	rewrite_log off;
  Контекст:	http, server, location, if

  Разрешает или запрещает записывать в error_log на уровне notice результаты обработки директив модуля ngx_http_rewrite_module.

  Синтаксис:	set $переменная значение;
  Умолчание:	—
  Контекст:	server, location, if

  Устанавливает значение указанной переменной. В качестве значения можно использовать текст, переменные и их комбинации.

  Синтаксис:	uninitialized_variable_warn on | off;
  Умолчание:	uninitialized_variable_warn on;
  Контекст:	http, server, location, if

  Определяет, нужно ли писать в лог предупреждения о неинициализированных переменных.

  Внутреннее устройство

  Директивы модуля ngx_http_rewrite_module компилируются на стадии конфигурации во внутренние инструкции, интерпретируемые во время обработки запроса. Интерпретатор представляет из себя простую стековую виртуальную машину. (/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break;

  Тогда соответствующие инструкции будут выглядеть так:

  проверка регулярного выражения
  копирование $1
  копирование "/mp3/"
  копирование $2
  копирование ".mp3"
  завершение регулярного выражения
  завершение всего кода
  

  Как настроить NGINX 301 Redirect

  NGINX — очень мощный инструмент веб-сервера для балансировки потребностей программного обеспечения или веб-приложения. Его используют почти 42,2% всех известных веб-сайтов и известных веб-серверов, чуть уступая Apache, который используется 43,3% всех веб-сайтов по состоянию на 2019 год. Излишне говорить, что это популярное и удобное программное обеспечение с открытым исходным кодом.

  NGINX 301 Перенаправления — это очень полезный способ правильного перенаправления адресов в браузере. Владельцам веб-сайтов обычно необходимо делать это при смене доменов или переупорядочении контента на своем веб-сайте.

  Так как именно выполняется это перенаправление? Давайте углубимся в то, как можно выполнить перенаправление NGINX 301 шаг за шагом.

  Связанный: Полное руководство для начинающих по отображению на первой странице Google

  Что такое перенаправление NGINX 301?

  NGINX — это тип программного обеспечения с открытым исходным кодом для кэширования, балансировки нагрузки, обратного проксирования и многого другого. Изначально NGINX разрабатывался как веб-сервер для повышения производительности и стабильности. Помимо возможностей HTTP-сервера NGINX, его также можно использовать в качестве прокси-сервера для электронной почты, а также в качестве обратного прокси-сервера и балансировщика нагрузки для различных типов серверов.

  NGINX 301 Redirect — это форма перенаправления HTTP. Можно использовать перенаправление HTTP, чтобы перенаправить один домен или адрес на другой домен или адрес. Существует несколько типов перенаправлений, каждый из которых имеет разное значение в клиентском браузере. Двумя наиболее используемыми и известными типами перенаправления являются «временные» перенаправления и «постоянные» перенаправления.

  Постоянные перенаправления, такие как NGINX 301 Redirect, просто заставляют браузер полностью забыть старый адрес и предотвращают дальнейшие попытки доступа к этому адресу. Эти перенаправления очень полезны, если ваш контент был постоянно перемещен в новое место, например, когда вы меняете доменные имена или серверы.

  Теперь, когда мы знаем, что такое NGINX 301 Redirect, давайте рассмотрим различные способы его настройки.

  Как настроить перенаправление NGINX 301

  Если вам нужно настроить перенаправление NGINX, вы можете выбрать один из нескольких вариантов.

  Самый простой и быстрый способ выполнить перенаправление — использовать оператор «return». Чтобы выполнить это утверждение, поместите следующий код в блок server :

  return 301 https://sample.com$request_uri; 9/foo/(bar)/(.*)$ $scheme://$server_name/$1/$2 Permanent;}

  Присоединяйтесь к более чем 1000 других компаний и проанализируйте свой веб-сайт с помощью Twiz

  Довольно просто, правда? Теперь, если у вас есть группа адресов или регулярных выражений, которые нужно перенаправлять по отдельности и по-разному, вы можете использовать карты. Карты могут быть определены в отдельных файлах, и их определения должны быть вне блока сервера. Это будет выглядеть примерно так:
  

  include redirect-map.conf;server {    […]    if ( $redirect_uri ) {        return 301 $redirect_uri; }}

  После выполнения файл конфигурации для карты перенаправления будет выглядеть примерно так:
  

  map $request_uri $redirect_uri {    /about.html          /about-us; /partners.html      /наши партнеры; /services.html       /our-services;}

  Стоит отметить, что регулярные выражения чувствительны к регистру символов. Сопоставление с учетом регистра должно начинаться с ~ , а сопоставление без учета регистра должно начинаться с ~*. Обратите внимание, что $redirect_uri можно назвать как угодно, но имя переменной в карте должно совпадать с именем блока сервера. Этот пример кода показывает это:
  

  карта $request_uri $redirect_uri {    /about.html          /about-us; /partners. html      /наши партнеры; /services.html       /наши-услуги; # Соответствует любому URL-адресу, который заканчивается на services.html или services.htm    ~services\.html?$    /our-services; # нечувствительная к регистру версия приведенного выше    ~*services\.html?$   /our-services; # Именованный захват, отображающий    # например. service-1234.html в /services/item-1234/overview    ~service-(?\d+)\.html   /services/item-$sku/overview;}

  Есть также дополнительные переменные, которые вы можете учитывать, которые уже предопределены в NGINX для использования в конфигурациях. К ним относятся:
  

  • $server_name. Это первое имя из объявления имени хоста в конфигурации для блока сервера, который немедленно отвечает на запрос.
  • $request_uri. Это полный унифицированный идентификатор ресурса (или URI) исходного запроса, который включает аргументы.
  • $запрос_имя_файла. Это путь к файлу для текущего запроса.
  • $схема. Это конкретная схема, используемая для вашего текущего запроса, например «https».
  • $хост. Это имя хоста, предоставленное клиентом для данного запроса.

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

  Вероятно, в NGINX можно использовать миллион различных способов перенаправления. Некоторые из них включают:

  9www\.(?.+)$ ) {    return 301 $scheme://$domain$request_uri;}

  HTTP на HTTPS

  Вы можете выполнить это перенаправление с помощью;
  

  возврат 301 https://$host$request_uri;

  Создайте каноническое имя хоста

  Это перенаправление полезно для предотвращения дублирования контента. Код будет выглядеть примерно так:
  

  имя_сервера sample.com www.sample.com запрос_ури;}

  Каким было наше руководство по выполнению перенаправления NGINX 301? Расскажите нам, что вы думаете, а также свои собственные советы по выполнению этого перенаправления в комментариях ниже.

  ‍

  301 Перенаправление с помощью nginx — Ошибка сервера

  Задавать вопрос

  спросил 2 года 3 месяца назад

  Изменено 2 месяца назад

  Просмотрено 2к раз

  Я переместил URL своего веб-сайта из этой формы:

   https://example.com/category/sub-category/post-url
  https://example.com/category/post-url
   

  в эту форму:

   https://example.com/post-url
   

  И я хотел бы настроить перенаправление nginx, чтобы не терять посетителей, проходящих по старым URL-адресам.

  Я нашел регулярное выражение, которое мне нужно использовать, это просто 9\/]+$) (Взять весь текст после последней косой черты). Но как я могу настроить его для использования с nginx?

  Это вывод nginx -T :

   root@ubuntu:~# nginx -T
  nginx: синтаксис файла конфигурации /etc/nginx/nginx. conf в порядке
  nginx: проверка файла конфигурации /etc/nginx/nginx.conf прошла успешно
  # файл конфигурации /etc/nginx/nginx.conf:
  www-данные пользователя;
  рабочие_процессы авто;
  pid /run/nginx.pid;
  События {
      worker_connections 1000;
  # multi_accept on;
  }
  http {
      ##
      # Базовые настройки
      ##
  client_max_body_size 30M;
      отправить файл включен;
      tcp_nopush включен;
      tcp_nodelay включен;
      keepalive_timeout 65;
      типы_хэш_макс_размер 2048;
      # server_tokens off;
      # server_names_hash_bucket_size 64;
      # server_name_in_redirect off;
      включить /etc/nginx/mime.types;
      default_type application/octet-stream;
  gzip включен;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";
  gzip_vary включен;
  gzip_types текст/обычный текст/текст css/изображение javascript/изображение svg+xml/приложение x-icon/приложение javascript/x-javascript;
      ##
      # Настройки SSL
      ##
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Удаление SSLv3, ссылка: POODLE
      ssl_prefer_server_ciphers включен;
      ##
      # Настройки ведения журнала
      ##
      журнал_доступа /var/log/nginx/access. log;
      журнал_ошибок /var/log/nginx/error.log;
      ##
      # Настройки Gzip
      ##
      # gzip_proxyed любой;
      # gzip_comp_level 6;
      # gzip_buffers 16 8k;
      # gzip_http_version 1.1;
      # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
      ##
      # Конфигурации виртуального хоста
      ##
      включить /etc/nginx/conf.d/*.conf;
      включить /etc/nginx/sites-enabled/*;
  }
  #почта {
  # # См. пример сценария аутентификации по адресу:
  # # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
  #
  # # auth_http localhost/auth.php;
  # # pop3_capabilities "TOP" "USER";
  # # imap_capabilities "IMAP4rev1" "UIDPLUS";
  #
  # сервер {
  # слушать localhost:110;
  # протокол pop3;
  # прокси включен;
  # }
  #
  # сервер {
  # слушать localhost:143;
  # протокол imap;
  # прокси включен;
  # }
  #}
  # файл конфигурации /etc/nginx/mime.types:
  типы {
      текст/html html htm shtml;
      текст/CSS CSS;
      текст/xml xml;
      изображение/gif gif;
      изображение/jpeg jpeg jpg;
      приложение/javascript js;
      приложение/атом+xml атом;
      приложение/rss+xml rss;
      текст/математика ммл;
      текст/простой текст;
      текст/vnd. sun.j2me.app-дескриптор jad;
      текст/vnd.wap.wml wml;
      текст/x-компонент htc;
      изображение/png png;
      изображение/tiff tif tiff;
      изображение/vnd.wap.wbmp wbmp;
      изображение/значок x ico;
      изображение/x-jng jng;
      изображение/x-ms-bmp bmp;
      изображение/svg+xml svg svgz;
      изображение/веб-сайт;
      приложение/шрифт-woff woff;
      приложение/java-архив jar war ear;
      приложение/json json;
      приложение/mac-binhex40 hqx;
      документ приложения/msword;
      заявка/pdf pdf;
      приложение/постскриптум ps eps ai;
      приложение/rtf rtf;
      приложение /vnd.apple.mpegurl m3u8;
      приложение/vnd.ms-excel xls;
      приложение /vnd.ms-fontobject eot;
      приложение /vnd.ms-powerpoint ppt;
      приложение /vnd.wap.wmlc wmlc;
      application/vnd.google-earth.kml+xml кмл;
      application/vnd.google-earth.kmz кмз;
      приложение /x-7z-сжатый 7z;
      приложение /x-cocoa cco;
      приложение/x-java-архив-diff jardiff;
      приложение/x-java-jnlp-файл jnlp;
      запуск приложения /x-makeself;
      приложение/x-perl pl pm;
      приложение/x-pilot prc pdb;
      приложение /x-rar-сжатый rar;
      application/x-redhat-package-manager об/мин;
      приложение /х-море море;
      приложение /x-shockwave-flash swf;
      приложение /x-stuffit сидеть;
      приложение/x-tcl tcl tk;
      приложение/x-x509-ca-cert der pem crt;
      приложение /x-xpinstall xpi;
      приложение/xhtml+xml xhtml;
      приложение/xspf+xml xspf;
      приложение/zip-архив;
      приложение/октет-поток bin exe dll;
      приложение/октетный поток deb;
      приложение/октет-поток dmg;
      приложение/октетный поток iso img;
      приложение/октет-поток msi msp msm;
      приложение/vnd. openxmlformats-officedocument.wordprocessingml.document docx;
      приложение/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx;
      приложение/vnd.openxmlformats-officedocument.presentationml.presentation pptx;
      аудио/миди мид миди кар;
      аудио/мпег мп3;
      аудио/огг огг;
      аудио/x-m4a m4a;
      аудио/x-realaudio ra;
      видео/3gpp 3gpp 3gp;
      видео/mp2t ц;
      видео/mp4 mp4;
      видео/mpeg mpeg mpeg mpg;
      видео/быстрое перемещение;
      видео/вебм вебм;
      видео/x-flv flv;
      видео/x-m4v m4v;
      видео/x-мнг мнг;
      видео/x-ms-asf asx asf;
      видео/x-ms-wmv wmv;
      видео/x-msvideo avi;
  }
  # файл конфигурации /etc/nginx/sites-enabled/default:
  сервер {
          корень /var/www/example.com;
          индекс index.php;
          имя_сервера пример.com;
          расположение / {
  try_files $uri $uri/ /index.php?q=$uri&$args;
          }
          расположение ~ \.php$ {
          включить фрагменты/fastcgi-php.conf;
          fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
          }
  расположение ~ ^/(?:[^/]+)(?:/[^/]+)?/(?. (.+?\.php)(/.*)$;
  # Проверяем существование PHP-скрипта перед его передачей
  try_files $fastcgi_script_name = 404;
  # Обойти тот факт, что try_files сбрасывает $fastcgi_path_info
  # см.: http://trac.nginx.org/nginx/ticket/321
  установить $path_info $fastcgi_path_info;
  fastcgi_param PATH_INFO $path_info;
  fastcgi_index index.php;
  включить fastcgi.conf;
  # файл конфигурации /etc/nginx/fastcgi.conf:
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param QUERY_STRING $query_string;
  fastcgi_param REQUEST_METHOD $request_method;
  fastcgi_param CONTENT_TYPE $content_type;
  fastcgi_param CONTENT_LENGTH $content_length;
  fastcgi_param SCRIPT_NAME $fastcgi_script_name;
  fastcgi_param REQUEST_URI $request_uri;
  fastcgi_param DOCUMENT_URI $document_uri;
  fastcgi_param DOCUMENT_ROOT $document_root;
  fastcgi_param SERVER_PROTOCOL $server_protocol;
  fastcgi_param REQUEST_SCHEME $схема;
  fastcgi_param HTTPS $https if_not_empty;
  fastcgi_param GATEWAY_INTERFACE CGI/1.1;
  fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
  fastcgi_param REMOTE_ADDR $remote_addr;
  fastcgi_param REMOTE_PORT $remote_port;
  fastcgi_param SERVER_ADDR $server_addr;
  fastcgi_param SERVER_PORT $server_port;
  fastcgi_param ИМЯ_СЕРВЕРА $server_name;
  # Только PHP, требуется, если PHP был собран с --enable-force-cgi-redirect
  fastcgi_param REDIRECT_STATUS 200;
  # файл конфигурации /etc/letsencrypt/options-ssl-nginx. conf:
  # Этот файл содержит важные параметры безопасности. Если вы измените этот файл
  # вручную, Certbot не сможет автоматически обеспечивать безопасность в будущем
  # обновления. Вместо этого Certbot напечатает и зарегистрирует сообщение об ошибке с указанием пути к
  # актуальный файл, на который вам нужно будет ссылаться при ручном обновлении
  # этот файл.
  общий ssl_session_cache: le_nginx_SSL: 10 м;
  ssl_session_timeout 1440 м;
  ssl_session_tickets выключен;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers выключен;
  ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA";
  # файл конфигурации /var/www/outpost.example.com/.nginx.conf:
  # Передать запросы, которые не ссылаются напрямую на файлы в файловой системе, в index.php
  расположение / {
    try_files $uri $uri/ /index.php?$query_string;
  }
  # Следующие директивы основаны на рекомендациях H5BP Nginx Server Configs. 
  # https://github.com/h5bp/server-configs-nginx
  # Срок действия правил для статического контента
  расположение ~* \.(?:манифест|appcache|html?|xml|json)$ {
    add_header Cache-Control "max-age=0";
  }
  расположение ~* \.(?:rss|атом)$ {
    add_header Cache-Control "max-age=3600";
  }
  расположение ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|mp4|ogg|ogv|webm|htc)$ {
    add_header Cache-Control "max-age=2592000";
    доступ_лог выключен;
  }
  расположение ~* \.(?:css|js)$ {
    add_header Cache-Control "max-age=31536000";
    доступ_лог выключен;
  }
  расположение ~* \.(?:ttf|ttc|otf|eot|woff|woff2)$ {
    add_header Cache-Control "max-age=2592000";
    доступ_лог выключен;
  }
  # Gzip-сжатие
  gzip включен;
  gzip_comp_level 5;
  gzip_min_length 256;
  gzip_proxy любой;
  gzip_vary включен;
  gzip_types
      приложение/атом+xml
      приложение/javascript
      приложение/json
      приложение/ld+json
      приложение/манифест+json
      приложение/rss+xml
      приложение/vnd.geo+json
      приложение /vnd.ms-fontobject
      приложение/x-шрифт-ttf
      приложение/x-веб-приложение-манифест+json
      приложение/xhtml+xml
      приложение/xml
      шрифт/открытый тип
      изображение/bmp
      изображение/svg+xml
      изображение/x-значок
      текст/кэш-манифест
      текст/CSS
      текст/обычный
      текст/визитная карточка
      текст /vnd. rim.location.xloc
      текст/vtt
      текст/x-компонент
      text/x-междоменная политика;
  # файл конфигурации /etc/nginx/uwsgi_params:
  uwsgi_param QUERY_STRING $query_string;
  uwsgi_param REQUEST_METHOD $request_method;
  uwsgi_param CONTENT_TYPE $content_type;
  uwsgi_param CONTENT_LENGTH $content_length;
  uwsgi_param REQUEST_URI $request_uri;
  uwsgi_param PATH_INFO $document_uri;
  uwsgi_param DOCUMENT_ROOT $document_root;
  uwsgi_param SERVER_PROTOCOL $server_protocol;
  uwsgi_param REQUEST_SCHEME $схема;
  uwsgi_param HTTPS $https if_not_empty;
  uwsgi_param REMOTE_ADDR $remote_addr;
  uwsgi_param REMOTE_PORT $remote_port;
  uwsgi_param SERVER_PORT $server_port;
  uwsgi_param ИМЯ_СЕРВЕРА $server_name;
   9/]+)?/(?.*)$ {
      вернуть 301 https://example.com/$posturl$is_args$args;
  }
   

  Блок location соответствует как одному, так и двум уровням префиксов каталогов и захватывает остальную часть URL-адреса в переменную $posturl .

  Затем переменная используется для создания перенаправления 301.