Эти 3 условия мы запишем так (в контексте server):
set $no_cache 0;
if ($request_method != GET) {
set $no_cache 1;
}
if ($query_string != "") {
set $no_cache 1;
}
if ($request_uri != "/") {
set $no_cache 1;
}
Вы проверили 1-й if, если значение истинно унаследовали внешнюю конфигурацию, проверили 2-й if, снова унаследовали внешнюю конфигурацию, проверили 3-й…
Тем самым при каждом запросе подпадающим под все три условия трижды наследуете конфигурации предыдущего уровня.
Как минимум их надо дополнить директивами break, чтобы избежать 3-йной проверки.
Как максимум:
Только главную страницу, то есть переменная $request_uri должна иметь значение "/".
Вынести обработку в отдельный location "=/"
Запросы типа GET и никакие другие. Следовательно значение переменной $request_method должно равняться GET.
Описать соответствующую директиву в map
Только те запросы, в которых нет GET параметров. Значит переменная $query_string должна содержать пустую строку "".
Использовать $query_string ($args) непосредственно в директивах fastcgi_cache_bypass и fastcgi_no_cache без всяких проверок в if.
Здесь нужно обращаться не в саппорт byfly, а непосредственно на БелПак, причем Минский (даже если проблемы в другой области). Вот только звонку вряд ли станут что-то делать, скорее всего пошлют на 123.
Пора делать community-driven репозитарий заблокированных сайтов в РБ
Уже не надо. Скоро в Беларуси не останется it-шников. Такого массового исхода не было никогда (и это с учётом практически закрытых границ). Это уже не миграция, это бегство из здешнего кошмара.
Количество трафика на них как раз не имело значения.
Скорее всего, в случае с *.github.io, сыграло роль наличие большого количества сайтов с инструкциями по настройке proxy, VPN, shadowsocks ссылки на которые начали появляться на популярных сайтах/форумах.
Стоит отметить, что блокируют сайты не все провайдеры: Белтелеком — точно, а вот, например, life пропускает траффик. В службе поддержки Белтелеком сказали, что у них блокировки нет никакой, а если у меня не открывается какой-то сайт, то они к этому не имеют никакого отношения.
Трафик на github.io нормально уходит через НЦОТ и блокируется на пограничных узлах БТК.
Аналогично (только наоборот) в примерах с 104.16.7.49 и 185.68.16.32.
Всё это наблюдается с момента «включения» интернета 12-го числа. Вероятно, когда DPI захлёбывался, часть роутов нулили вручную и забыли включить все обратно.
Ситуация в разных сетях отличалась. Даже в сетях одного провайдера (в одной автономке), но в разных подсетях картина была разная.
По ssh.
При использовании 22-го порта соединение отваливалось в течении минуты. После смены на нестандартные порты соединение не рвалось все 3-е суток.
По маскировке трафика под http.
In:
Необходимо было с фронтенда находящегося в Европе проксировать сайт на бакенд в Беларуси. Поток около 100 Mbps. По https дропалось 95+ процентов пакетов. После перевода бакенда на http (80-й) порт дропалось 70+ процентов. После перевода на нестандартный порт дропы практически прекратились, но при смене ip бакенда на адрес из другой подсети обмен трафиком почти полностью прекращался. При этом двухсторонние маршруты трассировки полностью совпадали.
Out:
Связка Shadowsocks+obfs(http) работала ~ в 70% случаев. Там где не работала локально приходилось проксировать в «рабочие» сети.
По Psiphon.
6 телефонов в одной комнате (оператор МТС). APK-шка одна и та же.
Работали:
HTC U11+
Samsung Galaxy Note10+
Samsung Galaxy S10+
Не работали:
HTC Bolt
Xiaomi Redmi 8
Xiaomi Redmi Note 9
Хуже всего было в первые 10-12 часов блокировки. В DPI, видимо, завернули весь трафик, а он смог обработать лишь 5-10% потока. Тут не спасали никакие решения.
И вопрос в том насколько просто вырубить только TOR и ничего больше.
Без мостов 30 сек. Достаточно скачать список нод и заблокировать их по списку на уровне первичных провайдеров.
В Беларуси часть IP Tor блокировалась и раньше (по спискам БелГИЭ) региональными провайдерами. Мосты ненадолго спасают, но редко больше чем на день. Уж не знаю вычисляют их вручную или получают обновления от китайских коллег.
Скажу больше, самый ценный (в техническом плане) комментарий на хабре мне оставил пользователь без единой статьи.
Комментаторы не менее ценны, чем авторы, но без статей авторов им нечего будет комментировать. Ну и я, например, просто не умею комментировать, поэтому практически перестал это делать.
На сайте НАСА есть небольшое пояснение по этому поводу — eclipse.gsfc.nasa.gov/SEhelp/dates.html
Ну и там же во всём обвиняют Дионисия Малого. Хотя, вроде не он, а Беда Достопочтенный окончательно решил, что после 1-го года до н.э. идет 1-й год н.э.
Редко, но всё же я пишу статьи на хабре. Случалось, что они занимали первое место в суточном рейтинге. И чертовски приятно открыть утром хабр и увидеть свою статью. Не на третьем, не на втором месте, а первой, без прокрутки страницы. Значит сообщество оценило мою писанину и 3 дня корпения над текстом были потрачены не зря.
Но сегодня я бы увидел на этом месте не то, что выбрали хабра-пользователи, а то, что их вынуждают читать хабра-редакторы.
да, этот проект для нас важен так же, как и Технотест
Знаете, если у пользователей растет количество строк «habr.com##» в uBlock Origin, то вы что-то делаете не так. Может стоить делать не то, что важно для вас, а то, что важно для ваших читателей?
TM_content, а вот этот пост действительно достоин места на главной? Его «закрепление» важнее суточного top-поста?
Ладно, прикрепленный пост «техно-текст-конкурса», но нахрена на этом месте этот шлак?
…
Не извиняюсь, реально наболело…
Ну он и появился от автора ipfw. Вот только его идеи не пошли дальше в штатный сетевой стек. В итоге стек Linux на ядрах 3.12 и 4.5 резко прогрессировал, а FreeBSD так и утилизируется на 100% при 100kpps syn-флуда.
Вы проверили 1-й if, если значение истинно унаследовали внешнюю конфигурацию, проверили 2-й if, снова унаследовали внешнюю конфигурацию, проверили 3-й…
Тем самым при каждом запросе подпадающим под все три условия трижды наследуете конфигурации предыдущего уровня.
Как минимум их надо дополнить директивами break, чтобы избежать 3-йной проверки.
Как максимум:
Вынести обработку в отдельный location "=/"
Описать соответствующую директиву в map
Использовать $query_string ($args) непосредственно в директивах fastcgi_cache_bypass и fastcgi_no_cache без всяких проверок в if.
Уже не надо. Скоро в Беларуси не останется it-шников. Такого массового исхода не было никогда (и это с учётом практически закрытых границ). Это уже не миграция, это бегство из здешнего кошмара.
Скорее всего, в случае с *.github.io, сыграло роль наличие большого количества сайтов с инструкциями по настройке proxy, VPN, shadowsocks ссылки на которые начали появляться на популярных сайтах/форумах.
Трафик на github.io нормально уходит через НЦОТ и блокируется на пограничных узлах БТК.
Аналогично (только наоборот) в примерах с 104.16.7.49 и 185.68.16.32.
Всё это наблюдается с момента «включения» интернета 12-го числа. Вероятно, когда DPI захлёбывался, часть роутов нулили вручную и забыли включить все обратно.
http://www.tutby.news/
UPD: но смотрю, что не полнофункциональное, часть ссылок ведёт на поддомены основного домена.
По ssh.
При использовании 22-го порта соединение отваливалось в течении минуты. После смены на нестандартные порты соединение не рвалось все 3-е суток.
По маскировке трафика под http.
In:
Необходимо было с фронтенда находящегося в Европе проксировать сайт на бакенд в Беларуси. Поток около 100 Mbps. По https дропалось 95+ процентов пакетов. После перевода бакенда на http (80-й) порт дропалось 70+ процентов. После перевода на нестандартный порт дропы практически прекратились, но при смене ip бакенда на адрес из другой подсети обмен трафиком почти полностью прекращался. При этом двухсторонние маршруты трассировки полностью совпадали.
Out:
Связка Shadowsocks+obfs(http) работала ~ в 70% случаев. Там где не работала локально приходилось проксировать в «рабочие» сети.
По Psiphon.
6 телефонов в одной комнате (оператор МТС). APK-шка одна и та же.
Работали:
HTC U11+
Samsung Galaxy Note10+
Samsung Galaxy S10+
Не работали:
HTC Bolt
Xiaomi Redmi 8
Xiaomi Redmi Note 9
Хуже всего было в первые 10-12 часов блокировки. В DPI, видимо, завернули весь трафик, а он смог обработать лишь 5-10% потока. Тут не спасали никакие решения.
Без мостов 30 сек. Достаточно скачать список нод и заблокировать их по списку на уровне первичных провайдеров.
В Беларуси часть IP Tor блокировалась и раньше (по спискам БелГИЭ) региональными провайдерами. Мосты ненадолго спасают, но редко больше чем на день. Уж не знаю вычисляют их вручную или получают обновления от китайских коллег.
Смена мостов также не дала результата.
Комментаторы не менее ценны, чем авторы, но без статей авторов им нечего будет комментировать. Ну и я, например, просто не умею комментировать, поэтому практически перестал это делать.
Ну и там же во всём обвиняют Дионисия Малого. Хотя, вроде не он, а Беда Достопочтенный окончательно решил, что после 1-го года до н.э. идет 1-й год н.э.
Но сегодня я бы увидел на этом месте не то, что выбрали хабра-пользователи, а то, что их вынуждают читать хабра-редакторы.
Знаете, если у пользователей растет количество строк «habr.com##» в uBlock Origin, то вы что-то делаете не так. Может стоить делать не то, что важно для вас, а то, что важно для ваших читателей?
Ладно, прикрепленный пост «техно-текст-конкурса», но нахрена на этом месте этот шлак?
…
Не извиняюсь, реально наболело…
для этого есть ключ serial
или так удобоваримее