Как-то слишком просто..

geo $force_bypass {
127.0.0.1 1;
default 0;
}

Добавил в fastcgi_cache_bypass $force_bypass

на запрос с localhost отдаётся новый контент, всё круто, в логах $upstream_cache_status=BYPASS, но кэш не обновляется и на запрос снаружи отдаётся старая версия с $upstream_cache_status=HIT. На диске в кэше лежит старый файл.

Чего не хватает котёнку?

> On 1 Aug 2018, at 18:28, Igor A. Ippolitov <iippolitov@nginx.com> wrote:
>
> Юрий,
>
> Если нужно заместить элемент, то даже отдельный location не потребуется:
> geo $bypass {
> 192.168.0.0/24 1;
> default 0;
> }
>
> И потом:
>
> location / {
> proxy_cache zone1;
> proxy_pass $upstream;
> proxy_cache_bypass $bypass;
> }
>
> В таком варианте, при обращении из 192.168.0.0/24 обращение в upstream будет мимо кэша. Но при этом, контент будет обновлён, если ответ в принципе может быть кэширован.
>
> Добавить в условие заголовки так же несложно. А вот аутентификация потребует дополнительных усилий.
>
> Так же можно сделать отдельный server{}, в котором использовать ту же зону, с теми же location'ами и задать там любые правила доступа.
>
> On 01.08.2018 16:48, Yury Lyakh wrote:
>> Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого самого специального локейшна?…
>> что-то не придумывается конфиг который позволит внутри nginx принудительно обновить элемент в кеше
>>
>>> On 31 Jul 2018, at 13:54, Igor A. Ippolitov <iippolitov@nginx.com <mailto:iippolitov@nginx.com>> wrote:
>>>
>>> On 31.07.2018 00:24, jd@jdwuzhere.ru <mailto:jd@jdwuzhere.ru> wrote:
>>>>
>>>>> On 30 Jul 2018, at 19:59, Igor A. Ippolitov <iippolitov@nginx.com <mailto:iippolitov@nginx.com>> wrote:
>>>>>
>>>>>> On 30.07.2018 14:29, Gena Makhomed wrote:
>>>>>>> On 30.07.2018 14:06, Igor A. Ippolitov wrote:
>>>>>>>
>>>>>>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле).
>>>>>> Замещать существующий контент или добавлять новый - да.
>>>>>> Но удалять не позволяет, в этом и состоит (небольшое) отличие.
>>>>> Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его.
>>>>> Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента
>>>> Погодите, я что-то потерялся. Есть профиль игрока, который не меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо обновить. Как без purge сообщить nginx, что информация обновилась и надо сходить в backend за новой страницей, чтобы положить её в кэш до следующего прихода?
>>> Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете.
>>>
>>> Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в следующий раз nginx перезапросит контент с апстрима.
>>> Этот запрос, обычно, приходит в отдельный location с нужными настройками: ключ кэша, права доступа, всякое такое.
>>>
>>> В моём подходе вы "дёргаете" такой же запрос в специальный location, который ходит в апстрим мимо кэша (proxy_cache_bypass).
>>> В разных вариациях, апстримом будет:
>>> либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0;
>>> либо реальный апстрим, который отдаст актуальную копию данных
>>>
>>> В первом случае контент сразу "протухает" и его актуализируют на первом же запросе.
>>> Во-втором - сразу актуальный.
>>>
>>> В следущий раз, когда запросят профиль пользователя, nginx либо пойдёт в апстрим, либо отдаст актуальную кэшированную версию.
>>>
>>>>
>>>>> На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях.
>>>>>> Вот поэтому и не понятно, почему нельзя сделать директиву
>>>>>> proxy_cache_purge доступной в open source версии nginx?
>>>>>>
>>>>>> Могу ошибаться, но коммерческую версию nginx покупают скорее всего
>>>>>> не из-за директивы proxy_cache_purge, а ради других возможностей.
>>>>>>
>>>>>>>>> Если не прояснится - попробовать воспроизвести как минимум без
>>>>>>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди
>>>>>>>>> отваживаются использовать эту поделку, она при любых внутренних
>>>>>>>>> изменениях в nginx'е разносит всё же)
>>>>>>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge,
>>>>>>>> то какие у пользователей open source версии nginx есть альтернативы?
>>>>>>>> Директиву proxy_cache_purge
>>>>>>>> можете сделать доступной в open source версии nginx?
>>>>>> P.S.
>>>>>>
>>>>>> Please do not top-post.
>>>>>>
>>>>>> Answer: Because it turns the discussion up-side-down.
>>>>>>
>>>>>> Question: Why should I not top-post?
>>>>>>
>>>>> _______________________________________________
>>>>> nginx-ru mailing list
>>>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>> _______________________________________________
>>>> nginx-ru mailing list
>>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru