nginx Как перезаписать все URL-адреса, кроме нескольких с указанными расширениями?

Я пытаюсь преобразовать правила перезаписи из файлов .htaccess в конфигурацию nginx . как часть переноса сайта на веб-сервер NGINX .

вот правила перезаписи из .htaccess файла

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_URI} !\.php$
RewriteCond %{REQUEST_URI} !\.gif$
RewriteCond %{REQUEST_URI} !\.jp?g$
RewriteCond %{REQUEST_URI} !\.png$
RewriteCond %{REQUEST_URI} !\.css$
RewriteCond %{REQUEST_URI} !\.js$
RewriteCond %{REQUEST_URI} !\.html$
RewriteCond %{REQUEST_URI} !\.xhtml$
RewriteCond %{REQUEST_URI} !\.htm$
RewriteCond %{REQUEST_URI} !\.ico$

RewriteRule (.*) index.php [L]
RewriteRule (.*).html index.php [L]

моей текущей конфигурации nginx .

server {
    listen       80;
    server_name  example.com;

    root   /usr/share/nginx/html;

    location / {
        index  index.php index.html index.htm;
    }

    location ~ \.(php)$ {
        try_files $uri =404;
        root           /usr/share/nginx/html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location !~* .(css|js|html|htm|xhtml|php|png|gif|ico|jpg|jpeg)$ {
      # Matches requests ending in png, gif, ico, jpg or jpeg. 
        rewrite ^(.*)$ /index.php break;
        rewrite (.*).html /index.php break;
    }

}

домашняя страница работает, но внутренние ссылки сайта дают 404.

до сих пор я пробовал много правил перезаписи, подобных этим.

if ( $uri  ~ ^/(?!(\.css|\.js|\.html|\.htm|\.xhtml|\.php|\.png|\.gif|\.ico|\.jpg|\.jpeg))) { 
    rewrite ^/(.*)$ /index.php break;
}

но иногда внутренняя ссылка работает, при перенаправлении всех статических файлов, таких как .css, .js, на домашнюю страницу , время от времени рабочие php-fpm начинают накапливаться, в результате этого также возникает процессор, подключения к sql и, в конечном итоге, процессор sql - к счастью, это никогда не длится слишком долго.

Я уверен, что это что-то удаленное, так как это происходит одновременно со всеми серверами, которые в настоящее время находятся под LB

По результатам моего исследования и тестирования, я думаю, что я отследил это до чего-то на веб-уровне, из-за которого процессы php зависли. ] Я считаю, что могу исключить подключения к моему кластеру ES, а также к RDS по нескольким причинам, - Отдельный мониторинг ES от конкретного хоста, у которого есть проблемы, теперь показывает проблемы - Все подключения к ES / SQL выполняются через уровень API, журналы API не показывают неудачных запросов (499/502), поскольку я получаю в веб-журналах. - Скрипт проверки работоспособности, который работает на php, вызывает данные из ES и SQL с самого веб-сервера, также не показывает проблем, в то время как веб-уровень начинает возвращать 499/502 - Дальнейший общий мониторинг среды SQL и ES не выявил проблем.

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

Я подозреваю, что часть php-запроса к веб-уровню требует, чтобы он генерировал ответ, который включает данные из внешних источников, некоторые из которых иногда не отвечают и приводят к зависанию ответа сервера.

Мне нужен способ чтобы доказать (или опровергнуть) это и идентифицировать соединения, я смотрел netstat, возможно, wirehark, но я мог бы помочь с определением команды, которая будет выделять либо сбой исходящего соединения, либо зависание - просто чтобы иметь возможность регистрировать любые исходящие соединения, которые занимают определенное время, были бы очень полезны, если проблемы совпадают с этими журналами, то я буду на правильном пути с некоторыми подсказками.

Я знаю, как я могу запустить это, как только соединения начнут истекать по таймауту, если нецелесообразно запускать его постоянно.

Надеюсь, вы, ребята, дадите мне несколько идей :)

Спасибо

0
задан 11 February 2017 в 15:26
1 ответ

Единственный способ получить необходимые данные - это выполнить захват пакета с полной информацией о пакете. Что-то вроде:

$ tcpdump -s0 -w packet.cap port 80 or port 443

Предупреждение, это займет дисковое пространство, поэтому убедитесь, что у вас достаточно места для хранения пакетов. После прохождения этого периода, когда проблема наблюдается, скопируйте файл локально и изучите его с помощью wirehark. Вы сможете проверить полные потоки TCP и HTTP-вызовы / ответы, как инициированные клиентами, так и инициированные вашим сервером.

Я бы спросил, однако ... вы уверены, что ваш сервер действительно запрашивает эти внешние ресурсы, а затем обслуживает их своим клиентам? В подавляющем большинстве случаев рекламные сети и т.п. обслуживают напрямую браузерам клиентов, а не через ваш веб-сервер.

0
ответ дан 24 November 2019 в 04:59

Теги

Похожие вопросы