Go + Windows = deadlock. Свет в конце тоннеля.

В прошлой статье я рассказывал о редком, но весьма опасном баге: поток под Windows зависал в вызове CancelIoEx, хотя документация Microsoft утверждает обратное. Суть проблемы — в пересечении синхронного и асинхронного ввода-вывода, где ядро Windows блокирует доставку APC, и поток остаётся навсегда «висящим».

История получила развитие не сама по себе: мы целенаправленно поднимали эту тему через support-кейс в Microsoft. В результате удалось подключить и Escalation Team, и разработчиков Go, ответственных за Windows-порт.

Финальный вывод: стандартная библиотека Go действительно использует неправильный API для отмены синхронных операций. Вместо CancelSynchronousIo, рекомендованного самой Microsoft, в коде до сих пор вызывается CancelIoEx.

👀 Сам проблемный вызов:
https://github.com/golang/go/blob/77f911e31c243a8302c086d64dbef340b0c999b8/src/internal/poll/fd_windows.go#L461

Хорошая новость: у команды уже есть рабочий proof-of-concept фикса:
https://go-review.googlesource.com/c/go/+/691395

Менее радостная часть: из-за сложности изменений и их влияния на рантайм правка запланирована только в Go 1.26 (февраль 2026). Бэкпорт в предыдущие версии практически исключён.

Что это значит для разработчиков

• Если ваш сервис на Go под Windows внезапно «зависает» в CancelIoEx — это следствие бага в стандартной библиотеке, а не ваша ошибка.

• До релиза Go 1.26 остаются обходные варианты:

  • не вызывать CancelIoEx для синхронных дескрипторов,

  • использовать CancelSynchronousIo, если есть возможность управлять потоками,

  • минимизировать использование пайпов в критичных местах.

Итог

Редкий flaky-тест Go (TestPipeIOCloseRace) оказался симптомом реальной и серьёзной проблемы. Благодаря эскалации через Microsoft Support и совместному разбору мы получили подтверждение, понятное объяснение и официальный фикс в планах.

⚡️ Если ваш Go-код на Windows зависает в CancelIoEx, теперь вы знаете: проблема признана и исправление уже в пути.

В одной из предыдущих статей мы обсуждали обход блокировки WireGuard VPN в Египте, направляя handshake-пакеты через SOCKS5 прокси. Однако, последние события показали, что этот метод больше не эффективен.

Вместе с Шэди Наги мы исследовали и протестировали новый подход. В предварительной версии WireSock VPN Client v1.2.41 был добавлен новый параметр Socks5ProxyAllTraffic. При установке в true (например, Socks5ProxyAllTraffic = true), он направляет весь трафик WireGuard через SOCKS5 прокси, эффективно скрывая его от DPI-анализа.

Обратите внимание, что возможно потребуется уменьшить MTU на 10-20 байт для учета заголовка SOCKS5 UDP.

WireSock VPN Client v1.2.41 доступен для скачивания по ссылкам из оригинального поста.

Для получения дополнительной информации и подробных шагов настройки, посетите руководство Шэди Наги.

Недавно мы узнали, что российский телекоммуникационный гигант "Мегафон" начал блокировать VPN-сервис Wireguard. Это вызвало определённое беспокойство среди пользователей, которые регулярно полагаются на VPN для защиты своей конфиденциальности и сохранения доступа к информации.

Пользователи отметили, что проблемы начались без предупреждения, что может свидетельствовать о том, что "Мегафон" начал целенаправленно блокировать Wireguard.

Но не всё так плохо, как кажется. Для тех, кто столкнулся с этими проблемами, хочется напомнить о методике обхода блокировок Wireguard, о которой я рассказывал в этой статье. Этот способ был изначально разработан для обхода блокировок в Египте, но, судя по информации, полученной от пользователей, он также эффективно работает для "Мегафона".