Наткнулся на небольшие грабли в nginx при установке https. В целом, сказанное здесь относится не только к nginx, но и к любому серверу занимающемуся терминацией SSL (TLS) и кешированием динамического контента.
Кеш NGINX, как и любой кеш, представляет собой key-value базу данных. NGINX при поступлении запроса ищет в нем нужный ресурс используя в качестве ключа хеш от неких параметров, указанных директивой proxy_cache_key.
По умолчанию она принимает следующее значение:
proxy_cache_key $scheme$proxy_host$request_uri;
Чем меньше переменных в ней указано, тем (незначительно) выше производительность, поэтому есть соблазн удалить первую переменную ($scheme — схема URL, принимает значения «http://» или «https://»).
Однако, как показала практика, это выливается в проблемы с отображением сайта через https. Происходит это потому что на запросы http и https будет отдаваться одна и та же страница, в которой, в зависимости от того, какой результат был закеширован, будут прописаны ссылки на http или https. То есть, если был закеширован ответ на запрос по незашифрованному http, то, обратившись на сайт по https, мы получим в ответ страницу со ссылками на контент по http, что выльется в криво отображенную страницу в браузере — без статики и с предупреждением «Эта страница содержит небезопасный контент«.
Поэтому, схему стоит указывать при настройке ключей для кеширования. Например, я данной директиве дал следующее значение:
proxy_cache_key $scheme$http_host$request_uri;