В нем содержится вызов функции конкретно вашего приложения, в результате, как правило, всё что вам нужно настроить в wsgi-сервере — это указать путь к этому файлу. Если бы он был один на весь фреймворк, то отличать одно приложение от другого пришлось бы как-то ещё, и virtualenv это более сложный способ, и не всегда необходимый. Ну и в конце-концов логично, что интерфейс связанный с конкретным приложением — лежит в папке приложения, а уж добавлять в него чего-то или нет — решать вам.
Этот файл необходим для подключения к wsgi-серверу, он содержит стандартный интерфейс для запуска вашего конкретного приложения (поэтому и создается при startproject).
Буквально глаза болят, и слова в предложения плохо складываются, когда такие вещи вижу. А может быть это просто такой глупый троллинг, тогда я вас покормил.
Любой человек, знакомый с nginx и читающий рассылку, или how-to на сайте, или pitfalls — знает почему так нельзя делать. У вас типичный совет из разряда от новичка — новичку, без какого-либо понимания как оно устроено и работает.
nginx построен так, что все специализированные задачи решаются очень быстрыми и эффективными алгоритмами. Так блоки server и директива server_name образуют очень быстрый хэш, который максимально заточен под поиск хоста. Если вы пишите if и внутри переменная $host — вы делаете явно что-то не так, вы используете директиву if не по назначению, и не используете специально предназначенную директиву server_name. В вашем случае она будет проверяться при на каждый запрос и на каждое внутреннее перенаправление, которые в nginx происходят во многих случаях неявно (например директива index всегда делает внутренний редирект, об этом написано в документации, но многие об этом не догадываются, кто ж читает документацию?).
Один минус вам можно было бы поставить за if, который будет выполняться на каждый запрос и который вам нужно писать в каждый блок сервер. Второй минус можно было бы поставить за использование регулярного выражения с целью тупого сопоставления строки (что директива if умеет без использования ресурсоемких регулярок, с помощью операторов "=" и "!="). Третий минус вам можно было бы поставить за caseless матчинг для переменной, содержимое которой и так приводится к каноническому виду — к нижнему регистру. Четвертый минус вам за бесполезное взятие регулярного выражения в capture group, что приводит только к трате тактов вхолостую, не бережете вы матушку землю. Пятый минус вам за точки, которые в регулярках имеют специальное значение — матчат любой символ (по умолчанию кроме перевода коретки), поэтому их надо экранировать, а иначе под ваше регулярное выражение совпадает не только с your.host.tld, но и множеством других доменов.
C proxy_pass у вас всё работало потому, что там есть встроенная магия. Эта директива умеет в себе совмещать функциональность директивы rewrite, если в ней указывать не только адрес сервера, а ещё и uri. Но мы, видимо, скоро от этой магии избавимся. Ибо как показал опыт, люди документацию не читают вообще и в результате, не понимают, как же оно работает, и далее, либо оно по случайности работает, как им и нужно, либо нет, и тогда начинаются вопросы.
Есть огромная разница между proxy_pass http://127.0.0.1:9010; и proxy_pass http://127.0.0.1:9010/; — обратите внимание на слэш на конце, который вам и обеспечил необходимое поведение.
fastcgi_param в конфигурации по умолчанию «fastcgi.conf», что идет в комплекте с nginx, устанавливается из переменных, зависящих от текущего uri, который и изменяет rewrite. Вы перемудрили, всё это крайне просто делается.
Между http://newsru.com/ и http://newsru.com есть существенная разница. Конфиг, который вы предложили, без слэша на конце действиетльно будет проксировать на http://newsru.com/news/.
Ну не обязательно. Насколько я понимаю, у вас сейчас access_log фактически дублируется. Достаточно его выключить на апаче, оставив под эту задачу только nginx.
