Windows — причина медленного интернета. Низкая скорость «загрузки», при нормальной скорости «скачивания»

Если Вы являетесь клиентом провайдера МТС «домашний интернет» и у вас проблемы со скоростью «загрузки» — это статья для Вас.

И если Вы проверили всё, что могло быть причиной медленной скорости загрузки: кабели, роутер, патч-корды, а в вашей Windows проблема осталась, не спешите паниковать, проблема не у Вас, а у вашего провайдера.

Дисклеймер
Данная статья основана на моих личных исследованиях и опыте, а также на предоставленных мной доказательствах и не несёт за собой цели кого-либо оскорбить. Я не преследую цели нанести ущерб репутации каких-либо лиц или организаций, а лишь стремлюсь к объективному освещению проблемы.

История

Началось всё приключение с 15 июня, тогда я проснулся в 2 часа ночи. У моего предыдущего провайдера снова были какие-то «технические работы», сидеть без интернета пришлось до 12 дня, а до этого с 5 утра и каждый час провайдер кормил обещаниями «мы всё исправим в течении часа». Поскольку это был не первый раз и к тому же цена за предоставление услуг обходится дорого, мною было принято решение поискать другого провайдера, так я наткнулся по совету жителей города на «МТС - домашний интернет».

Подключение прошло быстро. Однако, спустя пару часов я заметил странное явление, я не смог быстро загрузить файл на свою VPS размером 1 Гб, скорость была ~800 Кбайт/с. Я был удивлен, как такое может быть, заявлено по тарифу 500 Мбит/с, скачивание соответствует, а загрузка - нет!
Подумал в моменте, может автотюн винды глючит (надеялся на это, так могло всё быстро закончится), но оказалось, что не в этом проблема.
Также, я проверил второй компьютер, подумал, что может быть у меня проблемы с Windows, но нет! Проблема одинаковая на двух компьютерах, дело стало серьезнее.

Замеры скорости:

Яндекс.Интернетометр

SpeedTest

Waveform (ссылка на результат):

Поиски. Начало пути

Началось всё с обращения в тех. поддержку, техник пришел проверил кабель, стали сомневаться в кабеле. В итоге его поменяли, ситуация не изменилась.
Оперативность отличная, реально смотрели проверяли, коммутатор в подъезде тыкали смотрели и прочее, только это всё конечно же не помогло.

Тогда, я стал проверять скорость интернета на устройствах по дому. Проверяю с телефона (по Wi-Fi конечно) и вижу: скачивание ~190 мбит/с, загрузка ~245 мбит/с (проверял интернетометром).

Появился главный вопрос: кто виновник торжества?

Ищем то, не зная что

Моя история браузера заполнилась очень большим количеством запросов в поисковик.
Я прошелся по самым распространенным возможным вариантам проблем с интернетом, от всяких команд, скриптов PowerShell, разборки драйверов, заканчивая TCP оптимизаторами и как Вы могли возможно догадаться — это тоже не помогло.

Первая посещаемая мысль заключалась в том, что сегодня, в плане сервера, самым стабильным является ядро Linux. Это важная деталь, которая в дальнейшем сыграет ключевую роль, но об этом позже.
Набрав в поисковике модель сетевой карты "Realtek RTL8111H" от моей материнской платы (у меня B450 TOMAHAWK MAX II) с приставочкой "Linux", результатом выводится ссылка отправляющая меня на github.

Очень коротко говоря: я увидел tcp-bbr и информацию о том, что он имел когда-то проблему с ограничением пропускной способности, правда в ядре Linux.

BBR (Bottleneck Bandwidth and RTT) — алгоритм контроля перегрузки TCP, патчи с которым ещё в 2016 году были опубликованы компанией Google и приняты в основное ядро Linux. Применение этой технологии в некоторых случаях позволяет значительно увеличить пропускную способность канала передачи данных.

Дальше, я стал искать этот алгоритм у Windows 10. Его в этой версии не оказалось. Этот алгоритм есть в Windows 11, называется он bbr2, его можно включить и затестить вот так.

Для того, чтобы проверить этот алгоритм, с помощью rufus, на внешний ssd диск поставил Windows 11, однако, интересный факт, алгоритм bbr2 не является стандартным значением.
И по умолчанию, в обоих версиях Windows 10 & 11 стоит алгоритм CUBIC. Даже при попытке смены CUBIC на BBR2 в Windows 11, изменений в скорости интернета обнаружено не было.
Я не делал скриншоты этих проверок, но ветка комментариев из прошлой моей статьи имеет место быть.

Но, важный момент, который был проверен до проверки bbr2: скорость интернета от провайдера МТС каким-то чудом работает заявлено тарифу и выдает отличный результат (повторюсь, bbr2 и cubic на это не влияют):

Менять уже давно привычную Windows 10 на Windows 11 из-за проблем с интернетом, смысла не вижу. До этого у другого провайдера проблем не было, я получал заявленную по тарифу скорость. Поэтому, разбираемся дальше.

На тот период времени, у меня была Windows 10 21H2 (сборка чистого образа от 2021 года), в процессе поисков, а именно перетаскивая файлы из Win11 в Win10 я случайно сломал bootloader, поэтому после 2-х дней тщетных попыток восстановить его, мне пришлось переустановить Windows полностью со сборкой более свежей.
Это также играет определенную роль в этой истории. И помимо этого, я оставлю этот момент здесь, для тех у кого будет желание сказать мне, что можно попробовать переустановить систему.

Драйвера

И так, мне нужно было что угодно, чтобы увидеть другие цифры в скорости интернета.
Как типично бы не звучало, но драйвера это важная деталь в любой ОС, поэтому, чтобы убедиться в том, что они не являются помехой в этой истории, нужно перебрать все возможные варианты с их участием.

Первым в ход пошел сетевой драйвер — Realtek PCIe GBE Ethernet Family.
У меня стояла самая свежая версия, а в Windows 11 я обнаружил при тестировании, что используется версия от 2015 года! На дворе 2024 год, где искать такую версию драйвера?

Кое-как, но мне удалось найти драйвер от 23.12.2015, перед установкой полностью удалил сетевой драйвер и всё что с ним было связано, к сожалению, этот вариант тоже не помог.
Думаю, мне не нужно детально описывать то, что я пробовал менять различные настройки в драйвере по типу автосогласования и другие параметры, потому что и это не помогло.

Также, я ставил чистый образ Windows 10 на внешний ssd-диск для проверки интернета — результат как в самом начале статьи.

В поисках, я определил, что проблема кроется где-то в tcpip.sys (это системный драйвер протокола tcpip), но поскольку он системный, то сделать с ним к сожалению ничего нельзя. Либо можно, но ломать систему, не хотелось.

Второй роутер. Прошивка OpenWRT

В процессе перестановки основного роутера на другой, вспомнил о существовании кастомной прошивки OpenWRT. Решил попробовать её поставить на второй роутер, это был первый опыт пользования с данной прошивкой.

На тот момент у меня присутствовала мысль проверки интернета на Linux'е, но в смятении я не понимал, что мне это даст (исходя из того, что тест на Android был весьма положительным, позже были догадки, что именно Linux с сетью работает немного иначе, тем самым выдавая иной результат).

Хорошо, поставил, сунулся в настройки и был удивлен кучей возможностей (только всё ограничивается слабым процессором и малой памятью роутера). Что-то потыкав, мне ничего не помогло. Решил попробовать написать на форум OpenWRT с надеждой, может кто-то подтолкнет на путь истинный. И от этого, мои поиски продолжились уже на сайте microsoft среди огромной кучи вопросов и ответов.

Я прошерстил очень много тем у майков, дернув какие-то ключевые слова, мне удалось дальше продвинуться в поисках.

Политика QoS

По совету одного из комментариев на этой странице, нужно настроить политику QoS.

QoS (Quality of Service, или «качество услуги») — набор технологических решений для оптимизации сетевого трафика с помощью назначаемых приоритетов передачи информации.

Или проще: расставляет приоритет трафику, подобная настройка имеется в большинстве роутеров.

Это имеет одну из ключевых ролей (позже будет понятно почему), но не является как таковым решением для Windows 10 в моем случае. Проблема от этого, не ушла.

Большая пауза отправки пакетов

Очень редко когда мне приходилось использовать Wireshark для чего-либо, но в этот раз, на всякий случай, решил туда заглянуть. Открываю Wireshark, запускаю тест на Яндекс.Интернетометр'е и при «загрузке» вижу такую картину:

Протокол TCP так устроен, что должно быть подтверждение принимающей стороны после отправки от отправителя. Когда подтверждение не происходит, то по истечению времени отправляется новая порция сегментов. Так происходит циклично в процессе «загрузки», тем самым бОльшая часть сегментов просто сбрасывается, поэтому скорость загрузки колеблется очень низко от 10 до 50 Мбит/с.

Баг TCP в Windows 10

В моменте я уже понял, что проблема имеет прямое отношение к стеку протоколов TCP, соответственно запрос в поиске был следующий: «windows 10 bug tcp». И попадаю на такую ссылку.
На странице которой Gary Nebbett (автор книги Windows NT/2000 Native API, работал с операционными системами) дает ответ:

Алгоритм перегрузки TCP в Windows плавно перешел от обычных "dup ack" (повторных отправок подтверждения) к новому алгоритму RACK-TLP (Recent ACK, недавнее подтверждение).

Которое, как я где-то вычитал, вводилось экспериментально в Windows Server 2016, но потерпело крах, что привело к последствиям, которые проявились в будущем. Поэтому с новыми версиями Windows и Windows Server вносились исправления в алгоритм TCP-RACK. Подробности описывает один из разработчиков Microsoft

Проблема у DropBox

После того, как узнал о багах TCP, ссылка за ссылкой и попал сюда.

Команда DropBox подробно рассказывает о том, что столкнулись с проблемой клиентов, которые жаловались на медленную загрузку файлов на их сервера. Так они стали разбираться, подключив сюда несколько команд разработчиков, в том числе и Microsoft Core TCP Team (которые отвечают за работу TCP в Windows).

В статье обнаруживаются те самые «длительные периоды бездействия при загрузке», которые ранее я уже упомянул. Тогда стало понятно, я на ещё один шаг ближе к победе.

Пробуем Windows 10 от 2016 года

Всё, что мне удалось найти по поводу обновления протокола TCP, это было тут.

Тогда появилась идея, чтобы найти образ винды от 2016 года и проверить работу интернета там. Только вот момент: статья от июля 2016 года, в тексте говорится что microsoft «добавят» несколько новых алгоритмов для TCP. Значит, с января 2016 до июля 2016 года этого алгоритма точно нет. Мне не удалось найти точную информацию, в какой сборке и от какого месяца их уже добавили, но это не особо важно. (Смотрел даже здесь)

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

Поскольку SpeedTest лишь рисует красивые цифры, а мне нужна реальная картина, то обращаясь снова к Яндекс.Интернетометр делаю замеры, тест сразу после установки системы:

Увидев это, я разочаровался немного, но понимал, что должно быть как-то иначе, ведь здесь нет проблемного алгоритма TCP-RACK.
Тогда, я залез в настройки адаптера, отключил там QoS:

И увидел приятный результат:

Тут я сделал выводы, что в Win11 действительно алгоритм TCP-RACK (и возможно что-то ещё) был улучшен, так как скорость интернета на нем была выше на 20-30% чем на win10 от 2016 года.

Поиск подтверждения проблемы TCP-RACK

Единственное, что удалось найти к подтверждению теории, было обсуждение на github проекта gVisor от Google.

Автор обращается с проблемой о низкой пропускной способности из-за включенного TCP-RACK, скорость варьируется ~8 Мбайт/с, в случае отключения «восстановления потерь TCP» (т.е. TCP-RACK) скорость достигает ~80 Мбайт/с. По заявлению автора, проблема характерна для Windows Server 2022 и Windows 11.
Но, не стоит забывать о различных изменениях алгоритма в разных версиях Windows Server, как это было описано здесь.

Возможно, упомянутая проблема с некоторыми компьютерами на Windows 11 это ранние версии (в ссылке на github) и имеет прямое отношение к проблеме TCP D-SACK которую подробно описывал Gary Nebbett в своем блоге и которую Microsoft исправили, подтверждается это здесь.

Также, был комментарий под статьей от Microsoft с вопросом: «Когда добавят фикс в Windows 10?»
Официальный ответ разработчика:

«К сожалению, нет плана (по крайней мере, сейчас) по переносу изменений обратно в win10».

Спойлер: что на то время, что сейчас и что в будущем, этого плана никогда не будет, так как майки уже сделали полноценную ставку на свою сырую и баганную Windows 11.

Попытка отключения TCP-RACK

Открываем CMD (от имени админа) и смотрим текущие глобальные настройки шаблона TCP, с помощью команды «netsh int tcp show supplemental»:

Нашел такую команду для отключения TCP-RACK:
«netsh int tcp set supplemental Internet rack=Disabled»

Но, позже выяснилось, что изменение состояния RACK напрямую не возможно в Windows 10 (но возможно в Windows Server 2019/2022), поэтому можем поменять шаблон настроек TCP вот так: «netsh int tcp set supplemental Template=Compat» (в шаблоне Compat RACK отключен)
Результат:

На самом деле, эта попытка лишь попытка и не несёт за собой никакого положительного результата. Тем самым в очередной раз подтверждая, что проблема на стороне серверов провайдера.

И один в поле воин..

...если есть, за что бороться.

Я пытался найти кого-либо, кто мог бы знать какое-то решение этой проблемы. Мне нужна была база информации, чтобы обратиться в компанию МТС и сообщить, что дело-то серьезное. Я отправлял email нескольким людям (Gary N., автор проблемы с github, maolson из microsoft и еще пару человек).
Только Gary Nebbett ответил мне, сказав, что больше не занимался анализом сетевых проблем Windows после 22 года.

Тогда я понял, что всё печально.

Проблема по всей стране

С начала поисков прошло 10 дней, я стал собирать информацию о глобальности проблемы, вот что нашлось:

- Жалоба 1 (dtf)
- Жалоба 2 (answers microsoft #1)
- Жалоба 3 (answers microsoft #2)
- Жалоба 4 (answers microsoft #3)
- Жалоба 5 (mail.ru #1)
- Жалоба 6 (mail.ru #2)
- Жалоба 7 (mail.ru #3)
- Жалоба 8 (mail.ru #4)
- Жалоба 9 (qna.habr)
- Жалоба 10 (pikabu)

Это только те ссылки, авторы которых обращались куда-либо, что такая-то проблема и что делать.
Представьте лишь тот факт, сколько людей не обращались ни на какие форумы, сайты и прочее, чтобы попытаться узнать как решить данную ситуацию. Какой это процент текучки клиентов от компании? Сложно представить. А сколько негатива из-за этого? Ещё хуже...

IT-отдел компании — отказ от ответственности?

Один из техников компании МТС после моих обращений в тех. поддержку, сказал мне:

У нас айтишники говорят тестировать скорость только через speedtest, а к каким серверам обращается Яндекс (имеется ввиду интернетометр) тут я ничем не могу помочь.

Заведомо зная, что обращаясь к speedtest, который рисует результат скорости интернета (прям как на заборе) и ссылаясь на ветку комментариев под моей прошлой статьёй, можно предположить: приоритет настроен на speedtest (???)

Speedtest vs Яндекс.Интернетометр

В самом начале статьи, я показывал результаты этих двух сервисов. И приложил ещё один, который выдал схожесть с интернетометром.

Я частично доверяю speedtest'у, но только карандашиком

Edge vs другие браузеры

Исходя из этой ссылки (жалоба 1) и реальных фактов, замечено разное поведение теста скорости у SpeedTest в разных браузерах. Этому явлению я пытался найти ответ, но так и не удалось. Из предположений: провайдер отдает какой-то определенный приоритет по портам от Edge браузера либо Edge браузер как-то иначе коннектится к SpeedTest'у.

Из личных наблюдений, Яндекс.Браузер (сервер Ростелеком, г. Казань):

Яндекс.Браузер, сервер МТС, г. Ижевск

Edge браузер, сервер Ростелеком, г. Казань

Edge браузер, сервер МТС, г. Ижевск

Обратите внимание на первом скрине на «спад» скорости, на втором «ровность» скорости.
Окей, даже если предположим что это разные сервера в разных городах, то как найти объяснение «ровной» скорости для ростелеком города казань из под Edge?

Чем мешает такая низкая скорость

Проведение стримов становится адски невыносимой, битрейт ниже плинтуса, качество падает и прочие проблемы. Также, загрузка файлов куда-либо. В играх бывают пакеты теряются (packet loss).

Где наблюдается такая проблема

Win7 / 8 / 10.
Linux и Win11 работают отлично.

Обращение в компанию. Отправка письма

У меня уже была собрана определенная база информации. Проделано огромное исследование и я принялся писать письмо в компанию.

Это был мой первый опыт написания письма и его отправка почтой. Отправил первым классом с уведомлением о получении получателем, чтобы хотя бы знать, что оно действительно дошло куда надо.

1 июля письмо было отправлено, 4 июля получено, 9 июля взяли в обработку, а 12 июля мне позвонил руководитель монтажников по факту письма, чтобы сделать замеры скорости, собрать немного информации об этом, чтобы передать дальше.

Ответ компании

19 июля мне приходит СМС, в котором:

Мы все проверили. Ответ на ваше обращение №1-ххххх мы отправили заказным письмом

Ждал 8 дней, письмо мне не пришло, возможно оно затерялось. Я написал в тех. поддержку по факту данного вопроса, они переслали мне текст письма которое я должен был получить:

Мы проверили работу услуги «Домашний интернет» по вашему адресу, отклонений от технических норм нет. Скорость передачи данных совпадает с условиями вашего «Тарифа №1 092023» - 500 Мбит/секунду, в том числе на входящий трафик. Вы можете это проверить на сервисе speedtest.net.
Дарим скидку 40% на плату по тарифу. Теперь она 414 руб. в месяц до 16 сентября. Спасибо, что делитесь информацией. Мы всегда готовы к сотрудничеству, заполните форму на сайте partners.mts.ru

Сказать, что я даже не удивился, ничего не сказать. Это было ожидаемо.

Варианты решения на серверах провайдера

Предполагаю, что проблему можно решить либо одним из двух вариантов, либо двумя вариантами, либо проблема совсем в другом.

Вариант 1. Настройка QoS приоритета трафика.

Вариант 2. Отключение TCP-RACK

Вариант 3. Если оба варианта в пролёте, то пройти огромный путь выяснения причины. Потому что существует больше различных факторов по поводу проблем пропускной способности, однако, я отталкивался от того, что смог найти и доказать.

Решение доступное каждому пользователю

В моём приоритете было найти решение, которое каждый клиент «МТС - домашний интернет» может сделать для своего компьютера/ноутбука без сторонних устройств (по типу роутера). И такое решение есть, оно может показаться немного не удобным, но оно хотя бы есть.

_{Мне не удалось проверить решение только для Win7 / 8, но предполагаю, что в случае с проверкой Win10 от 2016 года, решение может быть аналогичное.}

Если у вас Windows 7 / 8 или 10 (2016 года), вам нужно всего лишь отключить QoS в настройках адаптера сети, как на скриншоте ниже:

Если у вас Windows 10 (от 2017 года и новее), то решение будет таким:

Что нам потребуется: WSL2 + Ubuntu 22.04 + Proxy server (linux) + Proxy client (windows)

Теория, зачем да почему:

Вспомним, ранее я говорил о том, что Linux с сетью работает немного иначе. Это было теорией, которую долгое время я не мог проверить.
Когда я вспомнил о существовании WSL (Windows Subsystem for Linux), тогда у меня была "старая" Windows 10 21H2 и я не смог его установить, была ошибка в Microsoft Store (возможно 0x80004002, но не уверен). По всякому пытался исправить, но не получилось. Потом переустановка системы и WSL всё же поставил через Microsoft Store.
Установил Ubuntu 22.04, проверил скорость через speedtest-cli:

Радоваться было рано, нужно было проверить теорию о том, что Linux работает иначе. Но были и сомнения.
Я никогда не пользовался WSL, поэтому как он работает мне было неизвестно.
Думал, что он как эмулятор, однако это оказалось далеко не так. Работает он как изолированная отдельная система, но под ядром Windows.
Мне был не понятен только один момент, как работает сеть у WSL таким образом, что само обращение к сети идет через тот же самый драйвер tcpip.sys из Windows, имея лишь виртуальный адаптер, который стучится к сетевому драйверу прикрученному к аппаратной части (т.е. к материнке). Таким образом, проблема обходится стороной, это мне и нужно было.

Адаптеры в настройках после установки WSL выглядят так:

Я проверял различные эмуляторы (vwware, virtual box, hyper-v, nox, smart gaga) и ни один из них не работает по такому же принципу сетевого подключения как WSL. Поэтому, я считаю, что это единственное решение данной проблемы.

Для проверки, я ставил OpenVPN на wsl и подключался к нему из под Windows, к сожалению это было плохой идеей, потому что скорость была 70 входящая и 30 исходящая, позже узнав, что OpenVPN режет скорость прилично.

Дальше, поставил прокси-сервер, подключился к нему из Windows и это дало результат:

Также, это работает и для sFTP (45,5 Мбайт/с):

Ещё тестировал стрим, с битрейтом проблем не было

Потеря входящей скорости примерно ~15-35%, но прирост исходящей (если возьмем, что таковая была 40 Мбит/с условно) составляет ~1250%!
В таком случае, скорость равняется в обе стороны, тем самым создавая баланс в приоритизации трафика.

Практика (установка)

1. Открываем CMD с правами администратора

2. Вводим wsl --install

3. После установки перезагрузите компьютер

Если, по каким-то причинам, Вы не можете установить WSL (ошибка Microsoft Store), то для исправления проблем с Windows вы можете её обновить (это не значит переустановить), тем самым сохранив все файлы. Но, я не гарантирую, что это действительно может исправить проблему, вы всё выполняете на свой страх и риск.

4. Снова открываем CMD с правами администратора

5. Вводим wsl --install -d Ubuntu-22.04

6. После завершения, нас попросят придумать username, введите что-нибудь простое (если после завершения ничего не происходит, то введите в CMD команду wsl)

7. Дальше попросят ввести password, поскольку мы не занимаемся раскрытием нашего компьютера в сеть, то можете поставить любую цифру или любую букву (но, если что, это противоречит безопасности!)

8. Далее попросят повторить пароль

9. После этого установка будет завершена

   

10. Вводим sudo apt update && sudo apt upgrade (нас могут попросить подтвердить действия паролем, вводим его)

11. Вводим sudo apt speedtest-cli (этот шаг не обязательный, но можно установить, чтобы позже узнать скорость интернета)

12. Если выполнили 11 пункт, то проверьте скорость интернета, введя speedtest-cli

13. Теперь скачаем Proxy сервер: sudo wget https://raw.githubusercontent.com/saaiful/socks5/main/socks5.sh

14. Установим Proxy сервер: sudo bash socks5.sh

15. Отлично! Прокси сервер запущен и настроен. Он будет автоматически включаться при запуске WSL.

16. Скачаем и установим необходимый драйвер для Windows.
    Окно с WSL НЕ ЗАКРЫВАЕМ иначе вы как бы «выключите» Linux.

17. Перейдя по ссылке ищем самый свежий релиз, находим в нём Windows.Packet.Filter.X.X.X.X.x64.msi

18. Скачаем для нашей Windows программу ProxiFyre для подключения к прокси серверу.
    Перейдя по ссылке, ищем самый свежий релиз, находим в нём «ProxiFyre-vX.X.XX-x64-signed.zip». Распаковываем и видим примерно такое:

17. Создаем в папке файл app-config.json

18. Закидываем туда такой конфиг

{
"logLevel": "None",
"proxies": [
{
"appNames": ["browser", "yandex", "filezilla", "fzsftp", "Telegram"],
"socks5ProxyEndpoint": "192.168.77.77:1080",
"supportedProtocols": ["TCP", "UDP"]
}
]
}

19. Его требуется отредактировать под свои нужды. Подробно расписано здесь

20. Нужно изменить имена процессов appNames под свои и нужно изменить socks5ProxyEndpoint . В appNames указаны имена процессов которые будут "захвачены" для того, чтобы весь трафик этих программ передавать на наш прокси-сервер. Имена можно указывать частично, полностью либо полный путь до программы.

21. Теперь узнаем IP адрес и поменяем его в "socks5ProxyEndpoint" . Для этого выполните команду ifconfig (в wsl) и рядом со слово inet будет ваш IP адрес который нужно будет вставить в app-config.json вместо 192.168.77.77 . Смотрите скриншот

22. Заменили, сохраняем документ. Открываем CMD от имени админа, переходим в папку распакованного ProxiFyre через cd /d "путь к папке"

23. Вводим ProxiFyre.exe

24. Готово! Если всё сделано правильно, то будет как-то так:

Теперь заходим в программы которые Вы прописали в конфиге и смотрим на результат!

Если в какой-то программе результата нет, ничего страшного, обратите внимание на конфиг.

Может быть такое (но с ProxiFyre у меня не было такого), что прописано верно, а результат нет. Если программа с которой Вы испытываете сложности поддерживает подключение к прокси-сервер, то авторизуйтесь в ней.

Не забудьте, всё делается от имени администратора.

Proxifier не советую из-за их бага драйвера, программа может просто перестать видеть процессы, которые нужно захватить и "проксировать". Но можете попробовать.

Мое мнение

Предыдущий провайдер оставил навсегда негативное восприятие. Технические работы всегда были не вовремя. Но, больше всего, что мне очень не понравилось, это попытка меня остановить от перехода к другому провайдеру и ладно если бы это было как-то лояльно, но с тоном попытки оказать давление, это уж чересчур. Я звонил для того чтобы расторгнуть договор, мне предлагали даже скидку, но я отказался и требовал расторжения. Меня спросили: "К какому провайдеру уходите?", ответил: "мтс", в ответ услышал: "ой, ну вот знаете, люди жалуются на мтс, также уходили, потом к нам возвращаются, а мы, кстати, федеральный провайдер, вы тоже к нам потом вернетесь!".
Осуждаю такое конкурентное давление, чисто из принципа не вернусь, даже если бесплатно интернет предложат на 5 лет вперед и оптоволокно мне через окно просунут.
Но, мне было интересно узнать, если действительно люди жалуются и уходят от «МТС домашний интернет», то должны же быть причины, так я и докопался до истины.

Когда ко мне приходили из "руководства монтажников", то смешным и забавным мне показался товарищ, который пытался всячески доказать мне, что текущая скорость загрузки (10-40 мбит) это нормально и проблемы нет! Если кто-то из компании действительно обратил внимание на данную статью, пожалуйста, займитесь своими «кадрами», потому что уверять, когда сам чего-то не знаешь, это странно.

Спасибо конечно за скидку в 40% до 16 сентября. Но, с учетом масштаба исследования, это как «иголка в стоге сена».

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

Сменю ли я провайдера в будущем — хороший вопрос, но не собираюсь.

Итоги

Плюсы: чистая винда, скидочка еще 1.5 месяца, новые знания
Минусы: нервы, время, винда

p.s. Некоторые совсем не нужные детали исследования были пропущены.