Автор статьи столкнулся с задачей заставить бесплатные языковые модели отвечать из России, обнаружив три основные проблемы и одну ловушку. Первая трудность заключалась в ошибке 403 Access denied by security policy, которая возникала при попытке использовать бесплатные модели через OpenRouter. Анализ заголовков ответа показал наличие поля CF-RAY, что указывало на то, что запрос блокировался на уровне Cloudflare из-за репутации IP-адреса, а не из-за неверного API-ключа. Смена ключа не помогала, так как блокировка привязана к IP, а не к учетной записи. Кроме того, автор заметил, что блокировка не зависит от конкретного дата-центра Cloudflare (HKG или DME), а определяется исключительно исходным IP-адресом пользователя.
Вторая проблема касалась использования Cloudflare WARP для обхода ограничений. Несмотря на рекомендацию установить бесплатный клиент WARP, автор не смог зарегистрировать аккаунт, так как серверы регистрации (188.114.97.170:894 и 162.159.192.1:894) были заблокированы, а домен api.cloudflareclient.com недоступен. В результате профиль WARP оставался пустым, а попытка подключения приводила к ошибкам парсера. Автор делает вывод, что WARP в России для этой задачи не работает, так как серверы регистрации недоступны, а даже при успехе пользователь попадал бы в ситуацию, где выходит в интернет через Cloudflare, который сам же и блокирует доступ.
Третья проблема возникла при выборе способа обхода блокировок. Автор отказался от полноценного VPN, требующего прав администратора для создания TUN-адаптера, и использовал локальный прокси (sing-box), слушающий на 127.0.0.1:18888. Однако была допущена ошибка при настройке: прокси был прописан в глобальной переменной среды HTTPS_PROXY. Это привело к тому, что все программы, включая игры и лаунчеры, пытались использовать прокси, что вызывало сбои и ошибки соединения (ConnectFail). Правильным решением оказалось задавать переменную прокси только внутри конкретного процесса запускаемого приложения, а не на уровне всей операционной системы.
Наконец, автор исследовал публичные репозитории с конфигурациями vless://, скачав более 3000 вариантов. Простая проверка открытости TCP-портов оказалась бесполезной, так как порт мог быть открыт, но TLS-сессия не поднималась. Реальная проверка требовала отправки HTTP-запроса через прокси и сравнения возвращаемого IP-адреса с исходным. Оказалось, что из 5681 конфигурации только две работали корректно. Автор также указал на распространенную ошибку в скриптах проверки: они часто показывают ложные результаты, считая успешный ответ сервера рабочим, даже если трафик прошел напрямую без использования прокси. Для корректной работы необходимо сравнивать выходной IP с IP-адресом пользователя и автоматизировать процесс отбора конфигураций.
