Практические заметки из маленького хоумлаба: Linux-серверы, nginx, certbot, Node.js под pm2, бэкапы restic, DNS и отладка Windows (падения, битая память, метрики CPU, PowerShell). https://home.tigran.manukyan.dev/ru/ 2026-11-05T12:00:00Z ~/home https://home.tigran.manukyan.dev/ru/notes/node-upgrade-under-pm2.html 2026-11-05T12:00:00Z 2026-11-05T12:00:00Z

При обновлении Node.js через nvm под pm2: привяжите nvm alias default к мажорной версии, поправьте сохранённый PATH в ~/.pm2/dump.pm2 для приложений в fork mode, перегенерируйте systemd-юнит pm2 с новым бинарником node и проверьте readlink /proc/PID/exe, прежде чем удалять старую версию.

<h1>Обновление Node под pm2 без сюрпризов</h1> <p class="meta">2026-11-05 · node, pm2</p> <p>Вышел security-релиз, и я перевёл несколько pm2-приложений на свежую версию Node через nvm. Сам <code>nvm install</code> занял минуту. А вот найти все места, где пряталась старая версия, вышло заметно дольше. Ниже порядок, который сработал с одним рестартом на каждое приложение.</p> <h2>1. Привяжите default в nvm к мажорной версии</h2> <p>Если <code>default</code> у вас указывает на <code>lts/*</code>, nvm переписывает этот алиас при каждом запросе списка версий. Как только новая ветка становится LTS, <code>default</code> начинает указывать на версию, которую вы не ставили, и новые шеллы стартуют вообще без <code>node</code>.</p> <pre><code>nvm install 24 --reinstall-packages-from=22 nvm alias default 24</code></pre> <p><code>--reinstall-packages-from</code> ставит ту же <em>версию</em> pm2, что была, а не последнюю. Здесь это ровно то, что нужно.</p> <h2>2. Приложения в fork mode помнят старый PATH</h2> <p>pm2 сохраняет окружение каждого приложения в <code>~/.pm2/dump.pm2</code>. Приложения в fork mode запускают <code>node</code> через сохранённый <code>PATH</code>, поэтому после рестарта демона они тихо продолжают работать на старом бинарнике. Приложения в cluster mode используют node самого демона.</p> <p>Сделайте бэкап дампа и замените старую версию в <code>PATH</code>, <code>NVM_BIN</code>, <code>NVM_INC</code> и <code>_</code>. <code>pm2 restart --update-env</code> тоже подойдёт, но если запускать его неинтерактивной командой по SSH, он подхватит урезанный PATH этого шелла.</p> <h2>3. Перегенерируйте systemd-юнит</h2> <p>В юните, который создаёт <code>pm2 startup</code>, путь к node зашит намертво. Сгенерируйте его заново с новым бинарником:</p> <pre><code>NEW=$HOME/.nvm/versions/node/v24.x.y sudo env PATH=$NEW/bin:$PATH $NEW/bin/node $NEW/lib/node_modules/pm2/bin/pm2 \ startup systemd -u $USER --hp $HOME sudo systemctl daemon-reload sudo systemctl restart pm2-$USER</code></pre> <p><code>pm2 update</code> по SSH для этого не подходит: он перезапустит демон внутри scope вашей SSH-сессии, а не под systemd.</p> <h2>4. Проверьте и только потом удаляйте</h2> <pre><code>for p in $(pgrep -f node); do readlink /proc/$p/exe; done | sort | uniq -c pm2 save</code></pre> <p><code>nvm uninstall</code> — только когда на старую версию больше ничего не ссылается.</p> https://home.tigran.manukyan.dev/ru/notes/snipping-tool-recycled-pid.html 2026-11-03T12:00:00Z 2026-11-03T12:00:00Z

Если по Win+Shift+S появляется только курсор загрузки, а процессы SnippingTool.exe копятся, помогает taskkill /f /im SnippingTool.exe. Причина в коде AppInstance из Windows App SDK: он считает переиспользованный PID живым и оставляет мьютекс захваченным.

<h1>Snipping Tool висит на курсоре загрузки: виноват переиспользованный PID</h1> <p class="meta">2026-11-03 · windows, отладка</p> <p>Перестал работать хоткей для скриншотов. Каждое нажатие на секунду показывало курсор загрузки и оставляло ещё один <code>SnippingTool.exe</code> без окна. Когда я наконец заглянул в диспетчер задач, их там висело 19.</p> <h2>Решение</h2> <pre><code>taskkill /f /im SnippingTool.exe</code></pre> <p>Убивать нужно все. Если по одному, то сначала прибейте ждущие, а потом тот, что держит лок, иначе ждущие проснутся и каждый откроет свой оверлей.</p> <h2>Что происходило</h2> <p>Wait Chain Traversal показал, что каждый новый экземпляр ждёт мьютекс, которым владеет один старый. Остальное прояснилось после чтения <code>AppInstance.cpp</code> в открытом Windows App SDK:</p> <ul> <li>Экземпляры регистрируют свои PID в общей секции памяти. При выходе свой PID никто не убирает, мёртвые записи вычищает следующий запуск.</li> <li>Единственная проверка «жив ли процесс» — удался ли <code>OpenProcess(SYNCHRONIZE)</code>. Если Windows уже отдала этот PID другому, постороннему процессу, мёртвая запись считается живой.</li> <li>Для каждого PID из списка новый экземпляр создаёт <code>&lt;app&gt;_&lt;pid&gt;_Mutex</code> с начальным владением, рассчитывая, что настоящий владелец создал его раньше. Если PID переиспользован, владельцем становится сам новый экземпляр и держит мьютекс до своего выхода.</li> <li>Отменённый скриншот (Esc) оставляет процесс висеть в памяти. Если именно он держит утёкший лок, все следующие запуски ждут вечно.</li> </ul> <p>У меня PID, который Snipping Tool использовал часом раньше, достался процессу Python. Через несколько часов один отменённый скриншот захватил лок, и хоткей умер.</p> <h2>Что пригодится при таких зависаниях</h2> <ul> <li>Событие 201 в журнале <code>Microsoft-Windows-AppModel-Runtime/Admin</code> фиксирует каждый запуск. Сравните со временем файлов в <code>Pictures\Screenshots</code> и увидите, какие запуски дали скриншот.</li> <li><code>cdb -pv -p &lt;pid&gt; -c "!handle 0 f Mutant; qd"</code> из Windows SDK показывает именованные мьютексы без символов и не останавливает процесс.</li> </ul> https://home.tigran.manukyan.dev/ru/notes/windows-cpu-percent-lies.html 2026-10-20T12:00:00Z 2026-10-20T12:00:00Z

Учёт загрузки по времени в Windows (диспетчер задач, GetThreadTimes, PDH % Processor Time) на частично нагруженном 8-ядерном 16-поточном CPU показывал до ~45% меньше, чем QueryThreadCycleTime. Чтобы понять, упираетесь ли вы в CPU, смотрите на загрузку GPU или GPU Busy в PresentMon.

<h1>Процент загрузки CPU в Windows врёт при частичной нагрузке</h1> <p class="meta">2026-10-20 · windows, производительность</p> <p>В диспетчере задач игры ни разу не грузили мой 8-ядерный CPU больше чем на 30%, даже когда явно упирались в процессор. Я написал небольшой генератор нагрузки и сравнил то, что показывает Windows, с тем, что процессор делал на самом деле.</p> <h2>Тест</h2> <p>Запускаем N потоков, которые крутятся без единой блокировки. Для каждого потока раз в секунду сравниваем два числа:</p> <ul> <li>время, которое ему засчитала Windows (<code>GetThreadTimes</code>, тот же источник, что использует диспетчер задач), и</li> <li>реально отработанные такты (<code>QueryThreadCycleTime</code>), делённые на частоту.</li> </ul> <h2>Что получилось</h2> <ul> <li>1 занятый поток: учёт по времени засчитал около 88% реального времени работы.</li> <li>8–12 потоков: падает примерно до 55%.</li> <li>Заняты все 16 аппаратных потоков: оба способа показывают 100%.</li> <li>Счётчик тактов всё время показывал 98–99%, и реальная производительность с ним согласна: 8 потоков сделали в 8,2 раза больше работы, чем один.</li> </ul> <p>При 8 полностью загруженных потоках общесистемный «временной» показатель был 28,5%, хотя реально была занята примерно половина машины. Другой счётчик, «% Processor Utility», ошибается в обратную сторону и показывает 80–85%, потому что масштабирует результат по частоте буста относительно базовой. Причём в простое он показывал около 13%.</p> <h2>Что я смотрю вместо этого</h2> <p>На вопрос «упираюсь ли я в CPU?» процент загрузки CPU почти не отвечает. Загрузка GPU ниже потолка или GPU Busy из PresentMon в сравнении со временем кадра отвечают на него напрямую. Заодно проверил один сторонний диспетчер задач: он читает те же временные счётчики, так что и занижает так же.</p> https://home.tigran.manukyan.dev/ru/notes/certbot-deploy-hooks.html 2026-10-12T12:00:00Z 2026-10-12T12:00:00Z

Сертификаты, выпущенные через certbot certonly, продлеваются, но nginx отдаёт старый, пока его не перезагрузить. Решение — исполняемый скрипт в /etc/letsencrypt/renewal-hooks/deploy/ с nginx -t && systemctl reload nginx, проверка — certbot renew --dry-run --run-deploy-hooks.

<h1>Certbot продлил сертификат, а nginx отдаёт старый</h1> <p class="meta">2026-10-12 · tls, nginx</p> <p>Таймер certbot в systemd исправно продлевает сертификаты. Подвох в другом: если сертификат получен через <code>certonly</code>, nginx никто не просит перечитать новый файл, и он отдаёт старый до следующего рестарта. Узнаёшь об этом примерно через 90 дней.</p> <h2>Решение</h2> <p>Кладём скрипт в папку deploy-хуков. Certbot запускает всё, что в ней лежит, после каждого успешного продления, и только тогда.</p> <pre><code>sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh &lt;&lt;'SH' #!/bin/sh nginx -t -q &amp;&amp; systemctl reload nginx SH sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh</code></pre> <p>Проверка <code>nginx -t</code> здесь не для красоты: если где-то лежит сломанный конфиг, reload всё равно упадёт, а так хук хотя бы не сделает хуже.</p> <h2>Как проверить, не дожидаясь трёх месяцев</h2> <pre><code>sudo certbot renew --dry-run --run-deploy-hooks systemctl list-timers | grep certbot</code></pre> <p>При dry run certbot пропускает deploy-хуки, если не передать <code>--run-deploy-hooks</code>, поэтому флаг и нужен.</p> https://home.tigran.manukyan.dev/ru/notes/monitor-that-forgets-to-listen.html 2026-10-10T12:00:00Z 2026-10-10T12:00:00Z

Старый DVI-монитор, который остаётся чёрным после загрузки или долгого пропадания сигнала, можно разбудить, переключив вход по DDC/CI (VCP 0x60) на VGA и обратно на DVI утилитой NirSoft ControlMyMonitor из задачи планировщика при входе в систему.

<h1>Старый монитор, который перестаёт ловить сигнал</h1> <p class="meta">2026-10-10 · железо, windows</p> <p>Мой второй экран — 22-дюймовая панель с наработкой около 35&nbsp;000 часов, подключённая по DVI. После каждой загрузки он оставался чёрным с включённой подсветкой. Windows его видела, кабель был в порядке, переподключение помогало. Надоело это очень быстро.</p> <h2>Сужаем круг</h2> <p>Монитор отвечает по DDC/CI, так что можно спросить у него самого, что происходит. В зависшем состоянии он сообщал правильный вход (DVI) и частоту вертикальной развёртки 0 (VCP <code>AE</code>), то есть просто не слушал сигнал.</p> <ul> <li>Воспроизводится так: Win+P → «PC screen only» на 40 секунд, потом «Extend». Разрыв в секунду (Win+Ctrl+Shift+B) проблему не вызывает.</li> <li>Повторный выбор DVI ничего не даёт. Перезапуск сигнала со стороны Windows — тоже.</li> <li>Переключение входа на VGA и обратно на DVI будит его каждый раз.</li> </ul> <h2>Обходное решение</h2> <p>ControlMyMonitor от NirSoft умеет писать VCP-коды из командной строки. VCP <code>60</code> — источник сигнала; у этого монитора 1 — VGA, 3 — DVI.</p> <pre><code>ControlMyMonitor.exe /SetValue "\\.\DISPLAY2\Monitor0" 60 1 timeout /t 2 ControlMyMonitor.exe /SetValue "\\.\DISPLAY2\Monitor0" 60 3</code></pre> <p>Пока монитор переключается, он игнорирует запись, поэтому настоящий скрипт повторяет команду, пока чтение <code>60</code> не подтвердит значение, а потом проверяет, что <code>AE</code> больше не 0.</p> <p>Скрипт запускается задачей планировщика при входе в систему, плюс второй триггер через минуту — на всякий случай. 26 загрузок подряд монитор зависал, и каждый раз скрипт будил его с первой попытки.</p> https://home.tigran.manukyan.dev/ru/notes/powershell-51-traps.html 2026-09-23T12:00:00Z 2026-09-23T12:00:00Z

Подводные камни Windows PowerShell 5.1: UTF-8 без BOM читается как ANSI, неудачный каст [xml] не останавливает скрипт, $null превращается в пустую строку в .NET-вызовах, возврат через унарную запятую ломает пайплайн, имена переменных не различают регистр, а коды выхода внешних программ надо проверять.

<h1>Ловушки PowerShell 5.1, которые вылезают только при запуске от админа</h1> <p class="meta">2026-09-23 · windows, powershell</p> <p>Написал скрипт для чистки системы и гонял его в режиме dry run без прав администратора. Все настоящие баги вылезли при запуске от админа. Вот те, что стоит запомнить.</p> <h2>Держите .ps1 в чистом ASCII</h2> <p>Windows PowerShell 5.1 читает UTF-8 без BOM в системной ANSI-кодировке (на русской Windows это cp1251). Один не-ASCII символ в регулярке превратился в кракозябры, и шаблон перестал совпадать.</p> <h2>Неудачный каст не останавливает скрипт</h2> <p><code>[xml]$x = $text</code> на кривых данных пишет ошибку и спокойно идёт дальше с пустым <code>$x</code>. Причём в текст ошибки попадает весь вход, а это могут быть мегабайты красного текста. Используйте <code>XmlDocument.LoadXml</code> в <code>try/catch</code> и обрезайте сообщение.</p> <h2>$null превращается в "" в .NET-вызовах</h2> <p>Если передать <code>$null</code> в .NET-параметр типа <code>string</code>, уйдёт пустая строка. Когда API действительно нужен NULL, передавайте <code>[NullString]::Value</code>.</p> <h2>Унарная запятая и пайплайн</h2> <p>Функция, которая заканчивается на <code>return ,$list</code>, отдаёт список одним объектом. Тогда <code>Get-Things | Where-Object { ... }</code> фильтрует весь массив как один элемент. Сначала присвойте результат переменной, а уже потом отправляйте в пайплайн.</p> <h2>Имена переменных не различают регистр</h2> <p>Локальная <code>$folders = @()</code> внутри функции перекрыла <code>$Folders</code> уровня скрипта. Цикл прошёл по пустому массиву, и скрипт отчитался об успехе. Давайте спискам из конфига имена, которые ни с чем не пересекутся.</p> <h2>Защитные проверки должны быть fail-closed</h2> <p>Начинайте с <code>$blocked = $true</code> и сбрасывайте флаг, только когда проверка полностью прошла. Моя первая версия делала наоборот, и ошибка парсинга пропустила бы скрипт дальше.</p> <h2>Проверяйте коды выхода внешних программ</h2> <p><code>pnputil /export-driver</code> падает, если целевой папки нет. Вывод уходил в <code>Out-Null</code>, так что этого никто не заметил, и следующая строка удалила пакет без бэкапа. Проверяйте <code>$LASTEXITCODE</code> <em>и</em> то, что файл действительно появился.</p> https://home.tigran.manukyan.dev/ru/notes/restic-systemd-timer.html 2026-08-30T12:00:00Z 2026-08-30T12:00:00Z

Бэкапы restic по systemd-таймеру (OnCalendar, RandomizedDelaySec, Persistent=true), очистка старых снапшотов через restic forget --prune, репозиторий и пароль в EnvironmentFile и пробное восстановление раз в месяц.

<h1>Restic на второй диск: скучно, зато работает</h1> <p class="meta">2026-08-30 · бэкапы</p> <p>Перепробовал несколько инструментов для бэкапов с веб-интерфейсом и в итоге вернулся к restic и systemd-таймеру. Работает только тот бэкап, который запускается без моего участия.</p> <h2>Сервис</h2> <pre><code># /etc/systemd/system/restic-backup.service [Unit] Description=restic backup [Service] Type=oneshot EnvironmentFile=/etc/restic/env ExecStart=/usr/bin/restic backup /etc /home /srv --exclude-caches ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune</code></pre> <p>В <code>/etc/restic/env</code> лежат <code>RESTIC_REPOSITORY</code> и <code>RESTIC_PASSWORD_FILE</code>. Права на файл — <code>chmod 600</code>.</p> <h2>Таймер</h2> <pre><code># /etc/systemd/system/restic-backup.timer [Timer] OnCalendar=*-*-* 03:30 RandomizedDelaySec=20m Persistent=true [Install] WantedBy=timers.target</code></pre> <p><code>Persistent=true</code> запускает пропущенный бэкап при следующей загрузке. Это важно для машины, которая в 3:30 бывает выключена.</p> <h2>То, что обычно пропускают</h2> <p>Раз в месяц стоит восстановить случайный файл куда-нибудь в сторону и открыть его. <code>restic check --read-data-subset=5%</code> тоже полезен, но он не покажет, получится ли найти нужный файл, когда он действительно понадобится.</p> https://home.tigran.manukyan.dev/ru/notes/bad-ram-badmemorylist.html 2026-08-14T12:00:00Z 2026-08-14T12:00:00Z

Случайные синие экраны Windows без единой ошибки WHEA оказались одним битым чипом на DDR4 без ECC. Одинаковые падения ILLEGAL_INSTRUCTION в одной общей DLL в разных процессах указали на плохую физическую страницу, MemTest86 это подтвердил, а bcdedit /set {badmemory} badmemorylist исключил эти страницы.

<h1>Битая память, одна общая DLL и badmemorylist</h1> <p class="meta">2026-08-14 · windows, железо</p> <p>Два месяца случайных синих экранов, и у каждого свой stop-код: битые PTE, CRITICAL_PROCESS_DIED, порча LIST_ENTRY, page fault'ы. Плюс несколько жёстких перезагрузок вообще без bugcheck. И ни одной ошибки WHEA.</p> <h2>Два неверных предположения</h2> <ul> <li><strong>«Событий WHEA нет — значит, не память».</strong> У обычной памяти без ECC нет обнаружения ошибок. Перевёрнутый бит до WHEA просто не доходит.</li> <li><strong>«Падения идут пачками, а не нарастают постепенно — значит, не железо».</strong> Одна битая ячейка даёт пачку падений, как только на неё попадает активно используемая страница, и затихает, когда страница переезжает.</li> </ul> <h2>Что выдало проблему</h2> <p>Три не связанных между собой сервиса упали с <code>ILLEGAL_INSTRUCTION</code> по одному и тому же смещению в одной и той же общей DLL, а хэш DLL на диске сходился. Windows отображает одну физическую копию кода DLL во все процессы. Если этот фрейм битый, каждый процесс декодирует один и тот же мусор. После перезагрузки страница переехала, и падения прекратились.</p> <h2>Подтверждение</h2> <p>Windows Memory Diagnostic (mdsched) нашёл ошибки уже на первом проходе. MemTest86 насчитал 3278 ошибок за 4 прохода даже на медленной штатной частоте. На тест row hammer пришлось только 12%, так что дело не в пограничных таймингах. 148 битых адресов легли в 16 страниц тремя кластерами, и сбоили всегда одни и те же два бита. Это один чип.</p> <h2>Огораживаем битые страницы</h2> <p>Windows умеет не использовать конкретные номера физических страниц (PFN):</p> <pre><code>bcdedit /set {badmemory} badmemorylist 0x5EF3E0 0x5EF3E1 ... bcdedit /enum {badmemory}</code></pre> <p>Каждый кластер я расширил до блока в 16 страниц, всего вышло 48. Потеря, которую не заметишь. Две вещи, которые надо знать:</p> <ul> <li><code>/set</code> заменяет список целиком. Чтобы потом добавить страницы, заново перечислите и все старые.</li> <li>Запишите, где лежат кластеры. Если следующее падение придётся на адрес вне их, чип деградирует, и одного списка уже мало. У меня так и вышло через два месяца, так что новая планка уже в списке покупок.</li> </ul> https://home.tigran.manukyan.dev/ru/notes/editor-update-deletes-editor.html 2026-07-27T12:00:00Z 2026-07-27T12:00:00Z

Cursor и другие редакторы на базе VS Code под Windows могут удалить сами себя при обновлении, если stdio MCP-сервер ещё работает на встроенном в редактор node.exe. Чтобы восстановиться, перенесите подготовленную сборку из папки _, а перед обновлением убивайте эти процессы.

<h1>Обновление редактора, которое удаляет редактор</h1> <p class="meta">2026-07-27 · windows, инструменты</p> <p>Дважды за месяц автообновление под Windows оставило меня вообще без редактора. Ярлык вёл в пустоту, а лог обновления рапортовал об успехе.</p> <h2>Что происходит</h2> <p>Редактор (Cursor, но апдейтер достался ему от VS Code) складывает новую сборку в подпапку <code>_</code>. Затем апдейтер удаляет старую установку <em>до того</em>, как переносит новую на место. А перед началом проверяет только, не запущен ли основной <code>.exe</code>.</p> <p>При запуске stdio MCP-серверов редактор ставит свой встроенный <code>node.exe</code> первым в PATH. Поэтому <code>npx some-mcp-server</code> работает на node редактора, и этот процесс живёт и после закрытия окна. Удаление натыкается на заблокированный файл, после нескольких попыток сдаётся и оставляет наполовину удалённую установку, а новая сборка так и лежит в <code>_</code>.</p> <h2>Как восстановить</h2> <p>Переустанавливать не нужно. Удалите выпотрошенную папку <code>resources</code>, перенесите всё из <code>_</code> на уровень выше и удалите <code>_</code>.</p> <h2>Как не допустить</h2> <p>Я отключил автообновление (<code>"update.mode": "none"</code>) и перед ручным обновлением проверяю, не остались ли висеть процессы:</p> <pre><code>Get-Process | Where-Object { $_.Path -like '*\cursor\resources*' }</code></pre> <p>Выключить сервер в настройках MCP недостаточно: у одного сервера дочерние процессы пережили выключение. Верьте списку процессов, а не интерфейсу. MCP-серверы по HTTP локально ничего не запускают, так что важны только stdio.</p> https://home.tigran.manukyan.dev/ru/notes/cache-folders-are-not-always-cache.html 2026-07-09T12:00:00Z 2026-07-09T12:00:00Z

Папки cache или depots внутри данных приложения могут хранить установленную сборку: удаление C:\ProgramData\LGHUB\depots сломало Logitech G HUB. Перед удалением проверьте манифесты приложения и по возможности пользуйтесь его собственной очисткой.

<h1>Папка cache — не всегда кэш</h1> <p class="meta">2026-07-09 · windows, уборка</p> <p>Системный SSD почти забился, и я пошёл по <code>C:\ProgramData</code> искать большие папки, которые выглядели как мусор. У Logitech G HUB нашлись гигабайты в <code>depots</code> и <code>cache</code>. Похоже на старые загрузки, так что я их удалил. G HUB перестал работать.</p> <h2>Чем на самом деле была <code>depots</code></h2> <p>Лежащий рядом <code>current.json</code> перечислял depot установленной сборки со статусом <code>"PRESENT"</code>. Приложение работает прямо из этой папки и проверяет её. Там лежала текущая версия, а не остатки старых. Помогла переустановка поверх.</p> <h2>Правило, которого я теперь держусь</h2> <ul> <li>Внутри папки данных приложения название вроде cache, depots или downloads ничего не доказывает. Сначала поищите манифесты или файлы версий, которые на неё ссылаются.</li> <li>Лучше воспользоваться встроенной очисткой приложения или его деинсталлятором.</li> <li>Если непонятно, записывайте папку в «может потребовать переустановки», а не в «безопасно».</li> <li>Обычные кэши по-прежнему можно чистить смело: npm, pip, кэши шейдеров, <code>%TEMP%</code>. Они пересобираются сами, так задумано.</li> </ul> https://home.tigran.manukyan.dev/ru/notes/measuring-dns-resolvers.html 2026-06-21T12:00:00Z 2026-06-21T12:00:00Z

Скорость публичного DNS зависит от маршрутов вашего провайдера. Замерьте 1.1.1.1, 8.8.8.8 и 9.9.9.9 из своей сети через dig со случайными, некэшированными именами и сравнивайте медиану и худший результат.

<h1>Замерьте DNS-резолверы, прежде чем выбирать</h1> <p class="meta">2026-06-21 · сеть</p> <p>Любой рейтинг «самых быстрых DNS» измерен из чужой сети. Anycast-маршрутизация зависит от пиринга вашего провайдера, так что резолвер, до которого у автора рейтинга 5 мс, у вас может оказаться в 60 мс.</p> <h2>Быстрый цикл</h2> <pre><code>for r in 1.1.1.1 8.8.8.8 9.9.9.9; do printf '%-10s' "$r" for i in 1 2 3 4 5; do dig @"$r" "example$RANDOM.com" +tries=1 +time=2 | awk '/Query time/{printf "%5s ms", $4}' done echo done</code></pre> <p>Случайное имя не попадает в кэш резолвера, поэтому замеряется полный резолв, а не ответ из кэша. Запустите в разное время дня: вечерние цифры обычно самые честные.</p> <h2>На что смотреть</h2> <p>Смотрите на медиану и худший результат, а не на лучший. Резолвер, который стабильно держит 8 мс, лучше того, что скачет от 3 до 90 мс.</p>