Сброс сетевых настроек Windows 10/11: исправляем ошибки IP-адреса и DNS в 2026 году

Короткий ответ: как сбросить сетевые настройки Windows

При ошибках «Нет допустимой конфигурации IP», сбоях DHCP или проблемах с DNS в Windows 10 и Windows 11 выполните диагностику, сбросьте Winsock и TCP/IP, очистите DNS-кэш, обновите DHCP-аренду и перезагрузите компьютер. После запуска Windows проверьте результат в порядке: ipconfig /all, ping шлюза, ping внешнего IP-адреса, затем nslookup доменного имени. Сама процедура занимает 5–10 минут, переустанавливать Windows для этого не нужно.

Откройте Windows Terminal или командную строку от имени администратора и выполняйте команды по одной:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Команды ipconfig /release и ipconfig /renew предназначены для адаптеров, которые получают настройки через DHCP. Если на компьютере задан статический IP-адрес, маска, шлюз или DNS, сначала запишите эти значения и не рассчитывайте на автоматическое восстановление конфигурации после сброса.

Перезагрузите Windows обычным способом или выполните shutdown /r /t 0. После перезагрузки не ограничивайтесь открытием одного сайта. Сначала убедитесь, что система получила корректный IPv4-адрес и шлюз, затем проверьте локальную связность, внешний маршрут и DNS-разрешение.

Короткий критерий результата: в ipconfig /all есть ожидаемые IPv4, маска, шлюз и DNS-сервер; шлюз отвечает на ping; внешний узел доступен или его ICMP-фильтрация объяснима; nslookup возвращает адрес для проверяемого домена.

Перед сбросом: определите, что именно сломалось

IP-адресация задает базовый путь компьютера к локальным и удаленным ресурсам. DHCP автоматически выдает адрес, маску, шлюз и иногда DNS-серверы. DNS решает отдельную задачу: преобразует доменное имя в IP-адрес. Поэтому отсутствие IPv4 нельзя исправить очисткой DNS-кэша, а рабочий DNS не заменяет корректный маршрут через шлюз.

До изменений сохраните исходную конфигурацию и определите границу сбоя. Такой подход помогает выбрать минимальное вмешательство. Дополнительный пошаговый сценарий есть в руководстве по восстановлению сетевых настроек Windows без переустановки системы.

Что посмотреть в `ipconfig /all` до изменений

Откройте обычную командную строку и выполните:

ipconfig /all

Найдите адаптер, через который компьютер должен выходить в сеть: Ethernet, Wi-Fi или виртуальный интерфейс. Проверьте несколько полей:

IPv4 Address, текущий адрес интерфейса;
Subnet Mask, маску подсети;
Default Gateway, адрес маршрутизатора для выхода за пределы локальной сети;
DHCP Enabled, признак автоматического получения параметров;
DHCP Server, узел, выдавший аренду, если DHCP используется;
DNS Servers, серверы, которым Windows отправляет запросы имен.

Адрес из диапазона 169.254.0.0/16, например 169.254.18.42, обычно означает, что Windows не получила рабочую DHCP-аренду и назначила себе локальный адрес. Такой адрес не подтверждает доступ к маршрутизатору или интернету.

Отсутствие Default Gateway ограничивает обмен локальной подсетью. Если шлюз пуст, компьютер может видеть соседние узлы, но не сможет отправлять трафик в другие сети. Пустое поле DNS Servers или адрес недоступного DNS-сервера объясняет ошибки разрешения имен, но не отсутствие самого IPv4-адреса.

Какие параметры сохранить перед сбросом

Сделайте снимок текущего состояния командой ipconfig /all и запишите значения в рабочую документацию. Для нестандартной маршрутизации дополнительно выполните:

route print

статический IPv4-адрес и маску подсети;
шлюз по умолчанию и статические маршруты;
адреса внутренних и публичных DNS-серверов;
настройки прокси Windows и браузера;
параметры VPN-профилей, сертификаты и способ авторизации;
SSID и ключ Wi-Fi, если после сброса потребуется повторное подключение;
настройки 802.1X, VLAN и корпоративных виртуальных адаптеров;
конфигурации Hyper-V, Docker Desktop, VirtualBox и других сетевых компонентов.

На рабочей станции, к которой подключаются по RDP, заранее подготовьте консольный или физический доступ. Сброс может разорвать текущую сессию и оставить компьютер без связи до ручного восстановления параметров.

Когда сброс действительно уместен

Сброс TCP/IP и Winsock подходит, когда сетевой стек Windows получил некорректные параметры после обновления, установки VPN-клиента, сетевого фильтра или неудачной смены конфигурации. Метод уместен при таких симптомах:

Windows сообщает об отсутствии допустимой конфигурации IP;
адаптер не получает новую DHCP-аренду после смены сети;
локальный стек TCP/IP работает нестабильно после удаления сетевого ПО;
приложения используют поврежденные записи Winsock;
старый DNS-кэш направляет запросы на неактуальные адреса.

Сброс не починит отключенный роутер, поврежденный кабель, неверный VLAN, неисправный Wi-Fi, недоступный DHCP-сервер или удаленный сервис. Блокировка ICMP тоже не доказывает повреждение Windows: маршрутизатор или сервер могут намеренно не отвечать на ping.

Windows не получает IP-адрес: как проверить DHCP до сброса

Начните с физического подключения и состояния интерфейса. Убедитесь, что кабель вставлен, Wi-Fi подключен к нужному SSID, адаптер включен, а компьютер находится в правильной VLAN. Затем сопоставьте результат с полями DHCP и Default Gateway в ipconfig /all.

Адрес `169.254.x.x` или отсутствие IPv4-адреса

Windows назначает адрес 169.254.x.x, когда не получает ответ от DHCP и не находит подходящую ручную конфигурацию. Такой результат указывает на проблему адресации, а не на DNS.

Проверьте следующие причины:

сетевой кабель, порт коммутатора и индикаторы линка;
подключение к правильной точке Wi-Fi;
состояние адаптера в списке сетевых подключений;
отсутствие ошибочного статического IP-адреса;
доступность DHCP в роутере или корпоративной сети;
совпадение VLAN и SSID с теми, где разрешена выдача адресов;
работу службы DHCP Client в Windows.

Если другой компьютер в той же розетке или Wi-Fi получает адрес из нужной подсети, локализуйте поиск на проблемной машине. Если адреса не получают несколько устройств, проверяйте DHCP-сервер, коммутатор, точку доступа или роутер.

Проверка шлюза и маршрута через `ping`

Возьмите адрес шлюза из поля Default Gateway. Например, если там указано 192.168.1.1, выполните:

ping 192.168.1.1

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

После успешного ответа шлюза проверьте внешний IP-адрес:

ping 1.1.1.1

Если шлюз отвечает, а внешний узел недоступен, ищите проблему в маршрутизации, правилах брандмауэра, роутере, провайдере или фильтрации ICMP. Один адрес не подходит как универсальный тест: конкретный узел может игнорировать запросы ping.

Как отличить локальный сбой от внешней проблемы

Сравните результаты минимум с одним другим устройством в той же сети. Для рабочей станции полезно проверить второй канал, например Ethernet вместо Wi-Fi или мобильную точку доступа, если политика безопасности это допускает.

Результат	Вероятная область поиска
Нет IPv4 или выдан адрес 169.254.x.x	Адаптер, кабель, Wi-Fi, VLAN или DHCP
IPv4 есть, шлюз не отвечает	Локальная сеть, порт, точка доступа, VLAN или firewall
Шлюз отвечает, внешний IP не отвечает	Маршрутизатор, провайдер, внешний маршрут или ICMP-фильтрация
Внешний IP доступен, доменное имя не разрешается	DNS-сервер, VPN-политика или локальный DNS-кэш

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

Сброс TCP/IP и Winsock Windows через командную строку

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

Откройте терминал с правами администратора

Откройте меню Пуск.
Введите Windows Terminal или cmd.
Выберите запуск от имени администратора.
Подтвердите запрос контроля учетных записей.

В заголовке окна обычно указано, что терминал запущен с правами администратора. Без повышенных прав netsh может завершиться с отказом в доступе или не изменить нужные параметры.

Не запускайте этот набор на удаленной машине по RDP без согласованного окна работ и резервного канала доступа. Сброс Winsock, TCP/IP и DHCP способен временно оборвать соединение.

Выполните команды для сброса сети в правильном порядке

Выполняйте команды последовательно. Дождитесь завершения предыдущей операции и сохраняйте текст ошибок:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Запуск всех строк одной длинной командой затрудняет поиск причины, если одна операция завершится ошибкой. Сообщение о необходимости перезагрузки после netsh int ip reset не означает, что остальные проверки уже прошли.

Что делает каждая команда

netsh winsock reset пересоздает каталог Winsock. В каталоге хранятся записи, через которые сетевые приложения обращаются к TCP/IP. Поврежденные записи могут появиться после установки или удаления VPN, фильтров безопасности и другого сетевого ПО.
netsh int ip reset сбрасывает параметры стека TCP/IP к стандартному состоянию Windows. После команды проверьте ручные настройки IP, маршрутов и DNS, потому что рабочая конфигурация может потребовать повторной настройки.
ipconfig /flushdns удаляет локальные записи DNS-кэша. Команда полезна, если Windows хранит устаревший ответ, но она не исправляет недоступный DNS-сервер или неправильную DNS-зону.
ipconfig /release освобождает DHCP-аренду на адаптерах с автоматической адресацией. На статическом интерфейсе операция не решает проблему и может завершиться сообщением о неприменимости.
ipconfig /renew запрашивает новую DHCP-аренду. Команда сработает только при доступном DHCP-сервере, активном интерфейсе и корректном подключении к нужной сети.

Команды воздействуют на разные уровни. Winsock отвечает за каталог сетевых провайдеров, TCP/IP хранит базовые параметры протоколов, DNS-кэш содержит локальные ответы, а DHCP выдает адресную конфигурацию. Поэтому один успешный шаг не подтверждает исправность всей цепочки.

Перезагрузите Windows после сброса

Перезагрузите компьютер через меню Пуск или из административного терминала:

shutdown /r /t 0

Закройте рабочие приложения и предупредите пользователей, если компьютер обслуживает общие ресурсы. После запуска Windows снова выполните ipconfig /all. Проверяйте параметры в заданном порядке: IPv4 и шлюз, ответ шлюза, внешний IP, DNS-запрос.

Если команды не показали явных ошибок, перезагрузка все равно нужна. Winsock и часть TCP/IP-параметров применяются полностью после перезапуска системы.

Полный сброс сети Windows 10/11 через параметры (Network reset)

Графический Network reset переустанавливает сетевые адаптеры и возвращает связанные параметры к стандартным. Это более радикальный вариант, чем отдельная очистка DNS-кэша или сброс Winsock. Используйте его, когда адаптеры отображаются некорректно, ручной сброс не помог или требуется переустановить сетевые компоненты Windows.

Путь к Network reset в Windows 11

Откройте Параметры.
Перейдите в раздел Сеть и Интернет.
Откройте Дополнительные сетевые параметры.
Выберите Сброс сети.
Нажмите Сбросить сейчас и подтвердите действие.

Windows предупредит о перезагрузке. Закройте сетевые сессии и подготовьте параметры Wi-Fi, VPN и статического IP до подтверждения операции.

Путь к сбросу сети в Windows 10

Откройте Параметры.
Выберите Сеть и Интернет.
Перейдите в раздел Состояние.
Откройте пункт Сброс сети.
Нажмите Сбросить сейчас.

Названия пунктов могут немного отличаться в отдельных сборках Windows 10. Если нужная команда не отображается, найдите в параметрах фразу Сброс сети.

Последствия полного сброса

После Network reset Windows удаляет сетевые адаптеры, устанавливает их заново и перезагружает компьютер. Подготовьте повторную настройку следующих компонентов:

Wi-Fi-профили и сохраненные беспроводные сети;
статический IP, маску, шлюз и DNS;
VPN-клиенты и виртуальные туннели;
прокси и корпоративные параметры авторизации;
виртуальные адаптеры Hyper-V, Docker Desktop и VirtualBox;
нестандартные маршруты и сетевые фильтры.

Не выполняйте полный сброс на удаленном сервере или рабочей станции, доступной только через текущий сетевой канал. Для нестандартной маршрутизации отдельно сохраните вывод route print. Команды добавления и удаления маршрутов собраны в руководстве по управлению маршрутами Windows.

Проверка после сброса сети: ipconfig, ping и nslookup

Проверяйте результат снизу вверх по зависимости: сначала локальная конфигурация, затем ближайший шлюз, внешний IP-узел и DNS. Открытие сайта в браузере не заменяет эту последовательность, потому что браузер может использовать собственный кэш, прокси, VPN или защищенный DNS.

Шаг 1. Проверьте IP-конфигурацию через `ipconfig /all`

ipconfig /all

Для DHCP-конфигурации ожидайте такие признаки:

у нужного адаптера есть IPv4-адрес из диапазона вашей сети;
маска соответствует подсети;
поле Default Gateway содержит адрес маршрутизатора;
DHCP Enabled указано как Yes;
присутствует адрес DHCP-сервера или система получает параметры согласно политике сети;
в поле DNS указаны доступные резолверы.

Адрес 169.254.x.x после перезагрузки означает, что DHCP-восстановление не завершилось. Отсутствие шлюза указывает на незавершенную маршрутизацию, даже если IPv4-адрес выглядит корректным.

При статической конфигурации сравните значения с сохраненной записью. DHCP может быть выключен намеренно, поэтому поле DHCP Enabled само по себе не служит ошибкой.

Шаг 2. Проверьте локальную связность через `ping`

Проверьте адрес из поля Default Gateway. Если шлюз равен 192.168.1.1, команда выглядит так:

ping 192.168.1.1

Ответы с небольшим временем и без потерь подтверждают связь компьютера с локальным маршрутизатором. При недоступном шлюзе проверяйте сетевой адаптер, кабель, Wi-Fi, VLAN и локальный брандмауэр. DNS на этом шаге еще не участвует.

Потери пакетов в беспроводной сети могут быть следствием слабого сигнала или помех. На проводном подключении повторите тест после проверки порта и кабеля.

Шаг 3. Проверьте внешний маршрут через `ping`

После успешного ответа шлюза выполните проверку известного внешнего IP:

ping 1.1.1.1

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

Для диагностики опубликованного сервиса с независимого сетевого сегмента можно временно использовать облачный сервер, например Timeweb Cloud. Такой тест помогает отделить проблему компьютера от недоступности конкретной инфраструктуры.

Шаг 4. Проверьте DNS через `nslookup`

Выполните DNS-запрос из командной строки:

nslookup example.com

Проверьте строки Server и Address, чтобы увидеть использованный DNS-сервер, а затем раздел с именем и возвращенными IP-адресами. Успешный ответ содержит адрес для запрошенного домена. Тайм-аут, сообщение о недоступности сервера или отсутствие адреса указывают на отдельную проблему DNS.

Для сравнения отправьте запрос напрямую к конкретному резолверу:

nslookup example.com 1.1.1.1

Если прямой запрос к указанному серверу работает, а обычный nslookup завершается ошибкой, проверьте DNS-серверы в ipconfig /all, настройки VPN и корпоративную DNS-политику. Очистка кэша командой ipconfig /flushdns не восстановит недоступный резолвер.

PTR-запись относится к обратному DNS, когда IP-адрес преобразуется в имя. Наличие PTR само по себе не подтверждает корректность обычного клиентского DNS. Для проверки FCrDNS имя из PTR должно разрешаться обратно в тот же IP-адрес. Для обычного доступа к сайтам достаточно сначала проверить прямой запрос имени, а обратный DNS использовать для отдельной задачи.

Подробная последовательность проверки DNS и дополнительные варианты сброса описаны в материале о проверке и сбросе DNS в Windows.

Как читать комбинации результатов

Проверка	Результат	Что искать дальше
`ipconfig /all`	Нет IPv4, адрес 169.254.x.x или нет шлюза	Адаптер, кабель, Wi-Fi, DHCP, VLAN и статическую конфигурацию
`ping` шлюза	Ответа нет	Локальную сеть, порт коммутатора, точку доступа, firewall и состояние интерфейса
`ping` шлюза	Ответ есть, внешний IP не отвечает	Маршрутизатор, провайдера, внешний маршрут и фильтрацию ICMP
`ping` внешнего IP	Ответ есть, `nslookup` не работает	DNS-серверы, VPN, корпоративную политику и DNS-кэш
`nslookup`	Имя разрешается, приложение не подключается	Прокси, VPN, firewall, TLS, порт и состояние самого сервиса

Успешный ping подтверждает доступность только проверяемого узла. Успешный nslookup подтверждает конкретный DNS-запрос, но не доступность веб-сервиса по HTTPS, работу прокси или правильность VPN-маршрута.

После сброса DHCP или DNS всё ещё не работает

Повторный сброс подряд редко меняет результат. Если параметры после перезагрузки снова некорректны, причина чаще находится в DHCP, физическом подключении, драйвере, статической конфигурации, VPN, firewall или внешней сети.

Команда `ipconfig /renew` завершается ошибкой

Проверьте, что адаптер включен и имеет физическое подключение. Для Ethernet проверьте линк и порт, для Wi-Fi, подключение к нужному SSID. В окне служб Windows найдите службу DHCP Client и убедитесь, что она запущена.

Дополнительные проверки в PowerShell:

Get-NetAdapter
Get-NetIPConfiguration
Get-Service Dhcp

Сопоставьте эти данные с ipconfig /all. Ошибка обновления аренды возникает, если адаптер отключен, компьютер подключен к неправильной VLAN, DHCP-сервер недоступен, задан конфликтующий статический IP или на роутере исчерпан пул адресов.

Проверьте DHCP на другом устройстве в той же сети. Если оно тоже не получает адрес, сброс Windows не устранит причину на роутере или корпоративном DHCP-сервере.

IP-связность есть, но доменные имена не разрешаются

Если шлюз и внешний IP отвечают, перейдите к DNS. Выполните оба запроса:

nslookup example.com
nslookup example.com 1.1.1.1

Сверьте DNS-серверы в ipconfig /all с настройками сети. В корпоративной среде внешний DNS может быть запрещен, а внутренние домены будут работать только через DNS компании. VPN-клиент может менять DNS после подключения и возвращать прежние параметры после отключения.

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

Локальная сеть работает, а внешние ресурсы недоступны

Если IPv4-адрес и шлюз в порядке и ping до шлюза проходит, а внешние адреса не отвечают, проблема уже не в сетевом стеке Windows. Проверьте по порядку:

настройки прокси в Windows и в браузере;
активные VPN-профили и политику маршрутизации трафика через туннель;
правила локального firewall и корпоративного сетевого фильтра;
состояние роутера, провайдера и внешнего маршрута;
доступность конкретного сервиса, а не всей сети.

Повторите проверку с другого устройства и, если возможно, через другой канал связи. Когда ресурс не открывается нигде, сброс сети на рабочей станции ничего не изменит.

Чек-лист: сброс сетевых настроек Windows по шагам

Сохраните вывод ipconfig /all и route print, запишите статический IP, DNS, VPN-профили и Wi-Fi.
Проверьте кабель, Wi-Fi, VLAN и адрес 169.254.x.x — такой адрес означает, что DHCP-аренда не получена.
Запустите терминал от имени администратора и выполните netsh winsock reset, затем netsh int ip reset.
Очистите кэш и обновите аренду: ipconfig /flushdns, ipconfig /release, ipconfig /renew.
Перезагрузите Windows командой shutdown /r /t 0.
Проверьте результат по цепочке: ipconfig /all → ping шлюза → ping внешнего IP → nslookup домена.
Если параметры снова некорректны, переходите к полному Network reset и проверке DHCP, DNS, драйвера и внешней сети.

Смежные сценарии: сброс сетевых настроек Windows через командную строку и диагностика, когда Windows не получает IP по Ethernet.