@Iron Bug Думаю, это для совместимости со старыми версиями какими-нибудь, где лежало в другом месте.

Вот в таких местах я рерайты и настроил :) Правда, не уверен в их пользе, так как 404 больше нет, но неправильный адрес почему-то перезапрашивается несколько раз. Вероятно, правильнее там дать всё же 404.

интереснно.
А второй запрос идёт к friendica.ironbug.org или к ironbug.org ?

@Хрень с лапками к friendica.ironbug.org. это всё логи конкретного сервера. у меня они разделены.

@Александр да это не старая версия, а настройка. можно настраивать виртуальные домены по имени домена, а можно по пути. но если уже обнаружен host-meta, то дальше, по идее, сервер должен работать с путями, которые в нём указаны. а он начинает высасывать какие-то левые пути. и главное, что он не один раз долбится, а получает 404 и продолжает долбить и долбить, будто 404 от упорного долбления превратится в нечто иное.

@Iron Bug Он и после 200 туда долбится в среднем от трёх до шести раз :)

@Александр если бы так. а то и по 150 раз иногда.

а с кэшированием забавная фигня получается. я наконец поняла, в чём главная жопа.
проблема в том, что у клиента есть скрипт, который получает данные. и он запрашивает у сервера запросы вида https://server.domain/display/long-resource-uid. и другие серверы тоже запрашивают этот же линк, но Content-Type у них разный: в случае с клиентом это text/html, а в случае с запросом от сервера это application/json.
и эта гадина при кэшировании мне сейчас вываливает закешированный json вместо html'а :)
я не сразу просекла, в чём фигня. теперь поняла. то есть, надо как-то HTML хэдер Сontent-Type присобавить к идентификатору кэша fastcgi_cache_key.
я сразу с ходу не могу сообразить, как это сделать. но наверняка можно как-то исхитриться через nginx'овские переменные.

ладно, пока я этот ад убрала. а то другие серверы тоже могут получить html вместо ожидаемого json'а :)
но надо над этим вопросом подумать.

@Iron Bug Просто добавить $content_type в ключи?
https://nginx.org/en/docs/http/ngx_http_core_module.html#variables

@Александр нет, не так всё просто.
тут ещё одна проблема вылезает. например, я открываю incognito-вкладку и открываю в ней ссылку на некий пост. и внезапно получаю закэшированный с куками "приватный" html.
я нашла обсуждение проблемы:
https://serverfault.com/questions/984561/nginx-cache-cookies-issue
там дан отвер, но его ещё надо переварить и, вероятно, адаптировать к френдике.
пока что я убрала Set-Cookie из игноров и решила подробнее разобраться, что и как кэшируется и как сделать так, чтобы кэширование было нормальным и безопасным.

@Александр но $content_type я добавила в хвост ключа. чтобы не было двойственности кэширования разных контентов, раз уж френдика их различает.

@Iron Bug Да, это должно помочь только от запросов с разным типом данных по тому же урлу. Дописал себе в ключи, посмотрим.

@Александр без игнорирования кук она и так их различает. пока не поняла, почему. во-всяком случае, при тех настройках, которые я описала в посте, она работает стабильно, что-то там кэширует, но не всё и не оптимально. я не очень понимаю, как куки влияют на кэш fastcgi запросов. вроде бы им должно быть фиолетово, ан-нет. пока этот момент для меня неясен.

вот же копнула тему! казалось бы, простой кэш, а сколько там подводных камней из-за особенностей реализации.

@Александр тащемта, похоже, что request в случае залогиненного юзера и левого посетителя сервера отличается только кукой с именем Friendica.
то есть, надо брать переменную "$cookie_Friendica" и прикреплять её в самый хвост ключа. да, ключ получится монстрозный :) надеюсь, там внутри хэши.

нет, один фиг запросы залогиненного клиента не кэшируются. ну, хоть часть кэшируется: общие запросы скрипта с длинными урлами.
похоже, куки тут присунуть не получится. придётся довольствоваться неполным кэшированием контента для залогиненного юзера.

@Александр по идее, чтобы убедиться, что всё правильно кэшируется и отдаётся, надо наблюдать логи на двух серверах.
потому что мало отдать 200. надо ещё отдать правильные данные. когда видишь ответ 200 - думаешь, что всё пучком, но на самом деле не факт.

@Александр я пока буду использовать твой сервер как контрольный: у тебя тоже кэширование включено и я в логах вижу нормальный обмен, без всяких ошибок.
я получаю твои комменты и ты вроде бы получаешь мои. значит, такое кэширование по крайней мере не ломает обмен данными на уровне серверов.
я вижу, что анонимный вход на сервер кэшируется (если аноним запрашивает пост, например). а залогиненный юзер не кэшируется (хотя в браузере работает кэш с диска). вроде всё выглядит более-менее прилично.
хотя я хотела бы добиться кэшированния повторяющихся запросов для залогиненного юзера. но про это надо ещё думать: можно ли это сделать безопасно и удобно для юзера.

@Iron Bug Да, пока всё ходит на вид нормально.
У меня, правда, щадящие настройки, я не стал исключать куки или no-cache - но всё же кое-что в кэш залетает :)