Игорь

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

Опишите процесс ресайзинга.
Тут у Вас явно должен быть механизм котоый в случае, если картинка не находится делал бы реврайт в скрипт, который должен ресайзить с передачей определенных параметров.
Скорее всего такое можно реализовать на try_files. Но без детального описания что и куда должно реврайтиться и с какими параметрами сложно что-то подсказать.

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

Попробуйте поискать руками в каталоге с кешем:
grep -r 'your_links' /nginx/proxy_cache_path
где /nginx/proxy_cache_path - каталог с кешем, указанный в конфиге nginx,
your_links- часть url страницы, которая должна была попасть в кеш.

Покажите вывод команд:
netstat -ntpua | egrep 'nginx|apache'

Можно еще убрать из configure:
--with-http_perl_module
Если Вы не собираетесь часть конфига на perl писать.
Вот описание модуля:
nginx.org/ru/docs/http/ngx_http_perl_module.html

Никак.
Можно только протестировать ее командой:
nginx -t

А что мешает сделать в nginx обычный proxy_pass ( nginx.org/ru/docs/http/ngx_http_proxy_module.html#... ) для location /service на второй сервер?
А на втором сервере уже обычная конфигурация Nginx Если надо можно закрыть все остальные location и отдавать с него только /service.

А почему не используете домены 3-го уровня, вида ghostsite1.domain.com, ghostsite2.domain.com и т. д.
Из плюсов можно сделать универсальтый конфигурационный файл nginx, где в зависимости от домена 3-го уровня будет формироваться переменная, на базе которой будет уже формироваться путь к корневой директории сайта root. Ну или просто для каждого домена 3-го уровня делать отдельный конфиг виртуального хоста по образу и подобию рядом лежащего (заменой пары директив).

У Вас случаем важная табличка в БД не лочится при работе парсеров?
Может парсер ее лочит, а все запросы к сайту ждут когда блокировка спадет?
Вы не мониторили, что с запросами происходит в БД, когда работает парсер?

Обычно во внутренней сети стараются упростить архитектуру.
Не рассматривали возможность просто сделать защищенный канал между ними? Допустим тот же openvpn будет шифровать весь трафик. Для подключения одного сервера (клиента) к другому (серверу) можно также использовать сертификаты.

Пробовали забирать простой файлик (не php)?
Что происходит если явно пробуете забрать какой-либо php файл? Например server.com/phpinfo.php
Что-нибудь пишется в error.log?

В настройках php (в файле /etc/php5/fpm/php.ini) проверьте, что:
short_open_tag = On
Если выключено, включите. и Перезапустите после этого fpm.

В nginx попробуйте установить:
fastcgi_param HTTPS on;

Также посмотрите на переменные для модуля ngx_http_ssl_module:
nginx.org/ru/docs/http/ngx_http_ssl_module.html
Можно попробовать из них взять нужную информацию.

Попробуйте сделать:
dpkg-reconfigure nginx
Ваши настройки он конечно не восстановит, но дефолтные файлы должен.

Попробуйте очистить кеш браузера.
В mozilla и chrome все перенаправилось с www на "без www".

в nginx.conf есть подключение файла с mime.types?
include /etc/nginx/mime.types;

В самом файле mime.types должно быть сопоставление для данных расширений:

text/css				css;
application/x-javascript		js;