bitrix php fpm config
Битрикс в связке Nginx+PHP-FPM, настройка ЧПУ, а так же композитный кэш с отдачей через nginx. Доработанная конфигурация
Цель: Предоставить конфигурацию виртуального сервера Nginx для работы Битрикс-cms в связке Nginx+PHP-FPM. Который в прочем подойдёт и для связки Nginx+Apache2, с небольшими доработками.
Целевая аудитория: Администраторы серверов, продвинутые администраторы сайтов, программисты.
Cтатей на эту тему достаточно, но если смотреть не официальные, то там как правило содержатся ошибки, а в официальных полно if которые в Nginx использовать не желательно. Надеюсь после того как я выложу данный конфиг к связке Nginx+PHP-FPM станут относиться серьёзнее.
Я покажу реализацию отдачи файлового композитного кэша. В целом отдача с memcached делается по аналогии. В конфигурации отдачи файлового кэша я насчитал 11 if, от которых я и избавился переделав их на map.
Начну с упрощённого варианта ЧПУ для тех кому нужна просто связка Nginx+PHP-FPM без отдачи композитного кэша через Nginx. Подразумевается что секция server уже настроена, с доменными именами и передачей в php-fpm.
Как не удивительно смотря на те полотна конфигов которые мне попадались, этого достаточно чтобы битрикс корректно заработал. Если нужен редирект с index.php и index.html на без, то нужно ещё дописать вот эту строку:
К сожалению тут достойной замене if нет. Но данная строчка работает не создавая проблем.
Хочу подчеркнуть что это именно минималистичная конфигурация без правил для статики, сжатия, и я там прикрыл только файлы композитного кэша от прямого доступа. Конфигурация которая прикрывает определённые места от прямого доступа через nginx довольно индивидуальна. У меня есть вот такой набор который может кому-то подойти. Но использовать нужно аккуратно с осознанием дела. Учитите что внесение данных локейшенов в свою конфигурацию может привести к неработоспособности сайта или части его функций.
Ну и конечно пример location для статических файлов
Теперь перейдём к конфигу для работы композита с отдачей файлов кэша через nginx. Первым делом необходимо определить можно ли отдавать данному запросу композитный кэш или его нужно отправить на обработку через php. Для этого в Nginx в секции http добавим несколько map, а так же несколько директив:
Далее уже непосредственно в секции server прописываем
Ну и для понимания как примерно будет выглядеть минимальная конфигурация секции server
Birtix + Nginx ( О нюансах перевода сайтов под управлением CMS «Битрикс» на работу через легковесную спарку «Nginx + PHP-FPM». )
28 июня 2017 (обновлено 2 декабря 2017)
OS: «Linux Debian 9», «Linux Ubuntu 16 LTS».
Расскажу здесь о некоторых особенностях настройки площадки для запуска сайтов под управлением CMS «Bitrix». Эта система управления контентом продвигается в продажах как средство легко и непринуждённо создавать сайты. В инструкции от разработчиков сайты под управлением движка «Битрикс» рекомендуется разворачивать в среде исполнения «Apache + modPHP», даже распространяют готовую сборку в этой конфигурации под названием «VMBitrix» на базе «CentOS/Ubuntu», но мне такой подход сильно не нравится и здесь будет изложена последовательность действий, которые необходимо предпринять для корректной работы CMS «Bitrix» с «Nginx + PHP-FPM».
Уже лет десять как прошло с того момента, как стало странно запускать сервисы непосредственно на аппаратуре физического сервера, так что да, мы готовим для web-сервера виртуальную площадку, соблюдая определённые условия.
В KVM-Qemu для виртуального диска и сетевой карты обязательно всегда использовать VirtIO-драйверы:
В VMware следует обязательно использовать драйверы «VMware Paravirtual (PVSCSI)» для виртуального HDD и «VMXNET 2/3» для виртуальных NIC:
Тест производительности дисковой подсистемы.
Тест записи, по возможности в обход «кеша»:
Выше приведены показатели тестирования вначале дискового массива «NetApp» из SSD, а следом SSD и обычного SATA2 дисков моей рабочей станции.
Защищаем административный вход.
Сразу после инсталляции базовых компонентов операционной системы запрещаем сетевой вход через SSH для суперпользователя.
.
# Отключаем возможность удалённого входа для суперпользователя
PermitRootLogin no
# Запрещаем использование «пустых» паролей при подключении
PermitEmptyPasswords no
# Запрещаем передачу пользовательских переменных окружения
PermitUserEnvironment no
# Запрещаем перенаправление портов пользователя и транзит подключений (это конечный сервер, а не «шлюз»)
GatewayPorts no
X11Forwarding no
.
Добавляем аккаунты web-разработчиков.
По хорошему web-разработчику нечего делать на web-сервере и проекты должны выгружаться в рамках процессов CI/CD, но реальность такова, что на мелких сайтах работа ведётся с кодом напрямую. Потому добавляем нужных пользователей:
Явно включаем пользователя в группу, от имени которой работает web-сервер:
Включаем для пользователя web-разработчика возможность через SUDO работать в окружении привелегий и переменных «www-data»:
Таким образом, например, web-разработчику можно будет изменить параметры запуска задач по расписанию:
Файловая структура сайтов.
Обозначу сразу незаметную многим начинающим специалистам особенность: в Linux файлы и директории по умолчанию создаются с групповыми разрешениями доступа «только чтение» (общесистемная установка «umask 0022»). Отсюда истекает проблема, когда файл созданный web-сервером или PHP-интерпретатором оказывается недоступным для изменения web-разработчику этого сервера. По мере развития Linux это решалось разными способами, но на данный момент проще всего переопределить политику доступа применительно к структуре директорий с помощью надстройки над подсистемой регулирования доступа «POSIX ACL».
Предпишем устанавливать всем создаваемым впредь файлам (и директориям) разрешения полного доступа как для владельца, так и группы, при этом ограничиваем чтение и запись всем остальным:
Проверить установки можно следующим способом:
Исполняемое ядро CMS «Bitrix» может быть использовано для обслуживания нескольких сайтов. В простейшем случае программное ядро и директория загрузки объектов группы сайтов выносятся отдельно от таковых и подключаются через символические ссылки.
Разделяемый между сайтами «one.example.net» и «two.example.net» движок «Bitrix» (впоследствии к этим двум сайтам можно «прилеплять» дополнительные, по отработанной схеме):
Разделяемая между сайтами «one.example.net» и «two.example.net» директория для загрузок файлов:
Разделяемая между сайтами директория временных файлов:
И файловая структура поддержки сайтов:
Символическими ссылками подключаем директории разделяемых ресурсов внутрь сайтов:
Конечно же, закрываем доступ к данным сайтов всем посторонним:
Рассматривать здесь полную настройку PHP-интерпретатора не вижу смысла и обращу внимание лишь на особенности, необходимые для работы.
В настройках FPM-пула изменим ряд параметров для достижения лучшей производительности:
Возьмём за основу конфигурационный файл PHP-FPM (как наиболее активно используемый):
После того, как мы удостоверились, что перезапись конфигурационных файлов сервисам не повредит, делаем это:
Перезапускаем сервис или велим ему принять новую конфигурацию, по ситуации:
Удовлетворяем ресурсные аппетиты Bitrix-сайтов.
CMS «Bitrix» даже в представлениях его разработчиков настолько прожорлив и неоптимизирован, что для удовлетворения требованиям PCRE-функциональности теста «самопроверки» (site_checker.php) размер доступного PHP «стека» приходится увеличивать в десять тысяч (. ) раз.
Прежде всего узнаём текущее значение размера стека (в Байтах), хотя бы и для того, чтобы потом зафиксировать изменения:
В рамках классического «unix-way» задаём новые ограничения пользователю, от имени которого запускаются наши web-приложения:
Для приложений, запускаемых через игнорирующий системные лимиты «Systemd» придётся создавать индивидуальные конфигурации.
Уточняем наименование сервиса, в рамках которого запущен PHP-FPM:
Просматриваем параметры текущей конфигурации сервиса:
Теперь можно воспользоваться встроенной функциональностью «systemctl edit php7.0-fpm.service» для дополнения существующей конфигурации, но я предпочитаю вручную создать в соответствующем месте директорию для автоматически включаемых сервисом дополнительных файлов конфигурации с удобным мне именем файла:
Указываем «Systemd» перечитать и принять новый набор конфигураций, после чего перезапускаем сервис PHP-FPM:
Особо одарённые стремлением курочить системные настройки могут внести свои параметры лимитирования прямо в файлы конфигурации сервиса «/etc/init.d/php7.0-fpm» или «/lib/systemd/system/php7.0-fpm.service», но это «фу-фу»-путь.
Чтобы убедиться, что лимиты настроены верно и применяются к целевым приложениям, можно проверить параметры лимитов прямо из PHP-скрипта:
Оптимизация работы PHP с дисковой подсистемой.
Место сохранения сессий в PHP определяется параметров «session.save_path» и по умолчанию оно располагается в директории «/var/lib/php/sessions». Точнее всего это выявляется через вывод функции «php_info()». Мне представляется самым простым смонтировать поверх этой директории кусочек «tmpfs»:
Монтируем или перемонтируем (если вносились изменения в уже существующую конфигурацию) «tmpfs»-файловую систему:
Прежде всего, для включения поддержки Nginx протокола HTTPv2 генерируем DH-сертификат:
Для очень старых ОС и браузеров (Windows XP IE6, Java 6) придётся снизить размер DH до 1024:
Конечно же защищаем директорию SSL-сертификатов от посторонних:
Слегка корректируем глобальную конфигурацию web-сервиса:
# Явно запускаем Nginx в рамках привилегий пользователя «www-data» и такой же группы «www-data»
user www-data www-data;
.
worker_processes 24;
.
events <
worker_connections 1024;
.
>
http <
.
tcp_nodelay on;
tcp_nopush on;
# Запрещаем web-серверу сообщать о себе подробные данные
server_tokens off;
# Запрещаем просмотр содержимого директории, если не указан целевой файл
autoindex off;
# Отключаем проверку размера тела передаваемого PHP-FPM запроса
client_max_body_size 0;
Описываем конфигурацию типового web-сайта под управлением CMS «Bitrix»:
# Перехватываем все запросы по протоколу без шифрования и перенаправляем их на HTTPS
server <
listen 80 default_server;
server_name one.example.net www.one.example.net;
access_log off;
error_log off;
location / <
rewrite ^ https://one.example.net$request_uri permanent;
>
>
# Перехватываем запросы к имени нежелательного формата и перенаправляем к нужному
server <
listen 443 ssl http2;
server_name www.one.example.net;
access_log off;
error_log off;
ssl on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.2048.pem;
ssl_certificate /etc/nginx/ssl/one.example.net.crt;
ssl_certificate_key /etc/nginx/ssl/one.example.net.key.decrypt;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_stapling on;
add_header Strict-Transport-Security max-age=15768000;
location / <
rewrite ^ https://one.example.net$request_uri permanent;
>
>
# Описывем рабочее окружение web-сайта как такового
server <
listen 443 ssl http2 default_server;
server_name one.example.net;
access_log /var/www/one.example.net/log/access.log;
error_log /var/www/one.example.net/error.log;
# SSL Configuration
ssl on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
# Old backward compatibility (Windows XP IE6, Java 6)
ssl_ciphers HIGH:SEED:AES128-SHA:AES256-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.2048.pem;
ssl_certificate /etc/nginx/ssl/one.example.net.crt;
ssl_certificate_key /etc/nginx/ssl/one.example.net.key.decrypt;
# SSL Caching
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
# SSL Verify Optional
ssl_stapling on;
# SSL Strict Optional
add_header Strict-Transport-Security max-age=15768000;
# Выключаем невостребованную обычно перекодировку контента
charset off;
# Явно указываем корень файловой структуры сайта, выше которой web-сервер не должен выходить
root /var/www/one.example.net/www;
# Задаём перечень файлов, которые web-сервер должен выдать в отсутствии явного указания со стороны клиента
index index.html index.htm index.php;
# Подставляем свою страницу обработки некоторых ошибок сервиса
error_page 500 502 503 504 /maintenance.html;
error_page 403 /403.html;
# Блокируем доступ к типовым «закрытым» ресурсам
location
* (/\.ht|/\.hg|/\.svn|/\.git|/\.enabled|/\.config) <
deny all;
log_not_found off;
access_log off;
>
# Блокируем доступ извне к внутренностям CMS «Bitrix»
location
* /(bitrix/modules|bitrix/managed_cache|bitrix/local_cache|bitrix/stack_cache|bitrix/backup|bitrix/tmp|upload/support/not_image|bitrix/php_interface|local/php_interface) <
deny all;
log_not_found off;
access_log off;
>
# Разрешаем доступ в административную панель Bitrix только избранным
location
# Разрешаем доступ только с определённого перечня IP-адресов
satisfy all;
allow 1.2.3.4/24;
deny all;
# Обрабатываем PHP-скрипты, доступные только после успешной аутентификации
location
# Включаем «HTTP Basic Authentication» для доступа к REST-API
location
# Обрабатываем PHP-скрипты, доступные только после успешной аутентификации
location
# Обработчик прямых обращений к PHP-скриптам
location
# Обработчик ошибок при доступе к ресурсам (таким образом в «Битрикс» реализована поддержка ЧПУ)
location @bitrix <
# Специфичная для Bitrix SEO-процедура подстановки к URL завершающего «/»
rewrite ^/(.+[^/])$ /$1/ permanent;
# Не реагируем на неинтересные события загрузок
location = /(404.html|favicon.ico|robots.txt|sitemap.xml) <
log_not_found off;
access_log off;
>
# Напрямую отдаём «статические» данные, предлагая браузеру сохранить их в своём «кеше», и не фиксируем в журнале эти события
location
Очевидно, что конфигурация Nginx для другого сайта будет отличатся лишь в части параметров включающих имя сайта «one.example.net», которое следует заменить на нужное.
Перед принятием в работу новой конфигурации обязательно просим Nginx проверить её синтаксическую корректность:
Старые клиентские системы и новые требования к SSL/TLS.
Наладка «HTTP Basic Authentication» посредством Nginx.
Если осуществляется полный переход с web-сервера «Apache» на «Nginx», то наверняка потребуется воспроизвести логику файлов «.htaccess», «.htpasswd» и «.htsecure» в части аутентификации пользователей при обращении к закрытым ресурсам.
Прежде всего ищем файлы точечной настройки и изучаем их функционал:
Особо важно не упустить блоков аутентификации средствами web-сервера при доступе к ресурсам, что-то вроде такого:
Подсистема «HTTP Basic Authentication» использует шифрование паролей на грани минимально допустимого с точки зрения устойчивости к взлому, но иногда приходится поддерживать совместимость со старыми протоколами, так что генерируем из желаемого пароля специфичного типа «хеш» (MD5-based password algorithm, Apache variant):
Полученный «хеш» подкладываем в файл с перечнем пользователей, доступ которым разрешается:
Рекомендую сразу запустить утилиту конфигурирования уровня безопасности СУБД:
Как и с PHP-интерпретатором «Битрикс» хочет от MySQL определённого. Предоставляем ему это:
.
[mysqld]
.
tmpdir = /var/lib/mysql/tmp
innodb_tmpdir = /var/lib/mysql/tmp
# Обязательно включаем приём подключений через файловый «сокет», существенно снижая операционные задержки
socket = /var/run/mysqld/mysqld.sock
# Разрешаем подключаться только с «localhost»
bind-address = 127.0.0.1
# Читаем документацию и подбираем подходящие параметры работы с доступной памятью
table_cache = 512
.
tmp_table_size = 512M
max_heap_table_size = 512M
.
query_cache_limit = 10M
query_cache_size = 256M
key_buffer_size = 512M //
20% RAM
.
innodb_buffer_pool_size = 1G //
60% RAM
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
.
innodb_read_io_threads = 16
innodb_write_io_threads = 16
# Явно указываем создавать для каждой таблицы отдельные файлы описаний (.frm) и данных (.ibd) на диске, а не сваливать всё в один (по умолчанию «ibdataX»)
innodb_file_per_table = 1
.
Параметры MySQL/MariaDB раскиданы по нескольким файлам в директории «/etc/mysql», так что есть смысл убедится, не переопределяются ли они где-то в «/etc/mysql/mariadb.conf.d/».
Для применения изменений перезапускаем СУБД или даём команду перечитать изменения, по необходимости:
Проконтролировать фактическое применение параметров можно через SQL-запросы:
Оптимизация работы MySQL с дисковой подсистемой.
Для СУБД MySQL, активно создающей и уничтожающей файлы для временных таблиц, выгодно вынести (параметром «tmpdir») эту работу в файловую систему, смонтированную в область памяти ОЗУ:
Добавляем в системный перечень монтируемых файловых систем нашу:
Монтируем или перемонтируем (если вносились изменения в уже существующую конфигурацию) нашу файловую систему:
Я бы выделил под эту файловую систему до 25% от объёма ОЗУ (она не заблокирует всё заявленное место, а будет выбирать блоки памяти по мере появления необходимости).
Разворачиваем БД для сайта.
Прежде всего потребуется создать «базу данных» и пользователя, от имени которого сайт будет обращаться к таковой:
Снимаем «дамп базы» MySQL исходного сервера (откуда осуществляется перенос сайта) и применяем его на новом сервере СУБД:
Для базы в целом (будет наследоваться после при создании новых таблиц):
Для таблицы (будет наследоваться при создании новых колонок):
Если таблица имеет внутри колонку в неверной кодировке, то можно это исправить за один проход, воздействуя на всю таблицу:
. или воздействовать точечно на нужную колонку таблицы:
CMS «Bitrix» весьма запутанная система, с массой подключаемых модулей, генерирующих большое количество блоков данных, используемых при генерации итоговых страниц из шаблонов. Вся эта неоптимальная деятельность сильно сказывается на отзывчивости сайта, терзая дисковую подсистему записью и считыванием информационного мусора, тормозя работу всех сервисов сервера в целом. Хорошо хоть часть этого промежуточного материала можно сохранять в кеширующем сервисе вроде «memcached» или «Redis»:
.
# Имя пользователя, для которого запускается сервис
-u www-data
# Количество одновременных подключений (по умолчанию 1024)
-c 1024
# Объем выделяемой памяти для кеша (по умолчанию 64MB)
-m 1024m
# Количество потоков Memcached (по умолчанию 4)
-t 8
# Выключаем прослушивание сетевого TCP-порта
#-l 127.0.0.01
#-p 11211
# Включаем работу через локальный файловый «сокет»
-s /tmp/memcached.sock
.
Настраиваем подсистему отправки почты.
Журнал регистрации событий утилита сама создавать не умеет, так что помогаем ей в этом:
Утилита «msmtp» способна полностью эмулировать классический «sendmail», так что для совместимости с уже настроенным по умолчанию программным обеспечением есть смысл сделать символическую ссылку, направляющую обращения в нужное место:
Для начала настроим один профиль, используемый по умолчанию:
# Set default values for all following accounts.
defaults
auth off
tls off
logfile /var/log/msmtp.log
# Default Account
account default
host mx.example.net
port 25
from www-data@one.example.net
Проверяем, работает ли это непосредственно из CLI сервера:
loaded system configuration file /etc/msmtprc
.
EHLO localhost
.
—> QUIT
Настройка подключения CMS «Bitrix» к БД.
$DBLogin = «user_one»;
$DBPassword = «user_password»;
$DBName = «one_example_net»;
$DBDebug = false;
$DBDebugToFile = false;
.
Кто заглядывал в PHP-код ядра «Битрикс», тот не удивится, зачем разработчики этой CMS требуют выключения режима строгого следования SQL-стандартам при формировании запросов к БД. В официальной инструкции предлагается сделать это глобально, для всей СУБД, но я предпочитаю всем остальным сайтам предоставить возможность работы в нормальных условиях, а «Битриксу» дать битриксово:
Замена пароля подключения к БД.
CMS «Bitrix» хочет, чтобы «всё было безопасно» и требует пароль подключения к СУБД состоящий из символов разного регистра и включающий в себя цифры со спецсимволами. Удовлетворяем его пожелания.
Генерируем кучу паролей и выбираем понравившийся:
Всё. Теперь в панели производительности Битрикс (http://site.com/bitrix/admin/perfmon_panel.php) должны увидеть подтверждение возможности использования этого типа кеша.
Особенность настройки FQDN.
CMS «Bitrix» активно использует для «самотестирования» обращения из своих скриптов к самим себе же, через обычные HTTP-запросы. Так вот, если в файле конфигурации локального «резольвинга» завязать доменные имена обслуживаемых сайтов на локальный IP (что часто случается на этапе первоначально наколенной разработки), то «самодиагностика» не состоится из-за сбоя авторизации при обращении к административной части сайта.
Адресация файловых систем.
Желательно удалить файлы, используемые лишь для инсталляции, а также случайно попавшие в дистрибутив:
Обновление «движка» CMS «Bitrix».
После запуска web-сайта на новой площадке возможно захочется протестировать, как скоро он сломается под возрастающей нагрузкой. Для этого можно воспользоваться утилиткой «Siege».
Вот так очень просто протестировать сервер в сценарии «250 пользователей 10 минут упорно ходят по сайту»:
[ уже посетило: 10385 / +5 ] [ интересно! / нет ]
Поблагодарить автора 
( сделайте свой денежный вклад в хорошее настроение )
битрикс + nginx + php-fpm
мне увы пока так и не удалось полностью подружить эту связку.
столкнулся с проблемой заголовков(при ЧПУ), т.е. получаем либо на все 200 OK либо 404 Not Found 
если интересно могу выложить конфиги.
совместными усилиями, собрали рабочий конфиг, спасибо Сергею Ляпко
UPD 23.12.2015: Добавил новый конфиг.
Старый
Evgeniy Pedan, наверно nginx кеширует страницу phpinfo() когда через админку Битрикс смотришь
/bitrix/admin/phpinfo.php?test_var1=AAA&test_var2=BBB#authorize
вот я конфиг nginx поменял, кеш видно сбросился.
Все работает, спасибо большое! Такая экономия времени.
* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)$ <
error_page 404 /404.html;
expires 30d;
>
вот этим:
location
* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)\?4*$ <
error_page 404 /404.html;
expires 30d;
>
Куда не вставляю location /bitrix/admin < return 404; >не работает, открывается админка
* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < access_log off; expires max; >#+ Close some uri for security location
Собственно рабочий конфиг (для оптимизации необходимо еще добавить другой 404 для статики ну и вообще посмотреть на дебаг на предмет лишних итераций)
битрикс + nginx + php-fpm
мне увы пока так и не удалось полностью подружить эту связку.
столкнулся с проблемой заголовков(при ЧПУ), т.е. получаем либо на все 200 OK либо 404 Not Found
если интересно могу выложить конфиги.
совместными усилиями, собрали рабочий конфиг, спасибо Сергею Ляпко
UPD 23.12.2015: Добавил новый конфиг.
Старый
Evgeniy Pedan, наверно nginx кеширует страницу phpinfo() когда через админку Битрикс смотришь
/bitrix/admin/phpinfo.php?test_var1=AAA&test_var2=BBB#authorize
вот я конфиг nginx поменял, кеш видно сбросился.
Все работает, спасибо большое! Такая экономия времени.
* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)$ <
error_page 404 /404.html;
expires 30d;
>
вот этим:
location
* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)\?8*$ <
error_page 404 /404.html;
expires 30d;
>
Куда не вставляю location /bitrix/admin < return 404; >не работает, открывается админка
* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < access_log off; expires max; >#+ Close some uri for security location
Собственно рабочий конфиг (для оптимизации необходимо еще добавить другой 404 для статики ну и вообще посмотреть на дебаг на предмет лишних итераций)