Network Reset Command Builder

Build the right Windows network reset command — and know which ones need a reboot

A machine says it is connected but nothing loads. Or a site resolves to an address it moved off last week. Or a VPN client was uninstalled and took the network stack down with it. The advice you find is always the same wall of commands pasted in one block, with no indication of which one addresses your symptom, which ones are harmless, and which ones do nothing until you restart.

This builder splits them apart. Choose what you actually want to reset and it gives you the exact command text, plus a clear warning when a reboot is required to complete it. It builds command text for you to copy — it does not execute anything, and nothing leaves your browser.

The six tasks, and their reboot requirement

That split is the whole point. The three no-reboot commands are cheap, reversible and take effect immediately — try them first. The two netsh resets rewrite persistent configuration and genuinely do nothing until the machine restarts, which is why so many people run them, see no change, and conclude the commands are useless.

Start with the cheapest fix that matches your symptom

ipconfig /flushdns clears the Windows DNS resolver cache. Use it when a name resolves to the wrong address — after a DNS record change, a certificate move, a hosts-file edit, or a site failover. It affects only resolution, takes effect instantly, and cannot break anything: the worst case is that the next lookup for each name is marginally slower because it has to go out to the server again.

Two things it does not clear, which is the usual reason people flush and see no change. Browsers keep their own DNS cache independent of Windows — Chrome and Edge expose theirs at chrome://net-internals/#dns and edge://net-internals/#dns, and restarting the browser clears it too. And your router or upstream resolver has its own cache with its own TTLs, which no command on your machine can touch.

Clear-DnsClientCache is the PowerShell equivalent of the same operation, and the builder offers it as its own task so you can paste it into a PowerShell session or a script without shelling out to ipconfig. Its useful companion is Get-DnsClientCache, which lists what is actually in the cache — look before you flush and you often learn what the problem is, because you can see the stale record.

ipconfig /release followed by ipconfig /renew drops your DHCP lease and asks for a new one. Use it when the address itself looks wrong: an APIPA address in the 169.254.x.x range (which means no DHCP server answered), a duplicate-address complaint, or a lease still pointing at the settings of a network you have since left. It is a DHCP operation only — an adapter with a manually configured static address ignores both commands entirely.

The obvious warning: between the release and the renew you have no address, so anything running over that connection drops. Never run this over Remote Desktop or SSH into the machine you are fixing. The release will succeed, the connection will die, and the renew will never arrive.

The two commands that need a restart

netsh winsock reset restores the Winsock catalog to its default state. Winsock is the sockets layer every network application goes through, and third-party software can insert itself into that catalog as a layered service provider — VPN clients, endpoint security products, proxy and filtering agents, older download accelerators. When one of those is removed badly, or corrupts its entry, the symptom is unmistakable: the machine has a valid address, ping works, and yet browsers and applications cannot connect. That is the case this command is for.

It has a real consequence. Resetting the catalog removes those third-party entries, so software that installed one may stop working until it is repaired or reinstalled. That is usually the fix rather than the damage — but if a VPN or security client stops functioning after this, reinstalling it is the expected next step, not a new problem.

netsh int ip reset rewrites the TCP/IP configuration in the registry back to defaults. Use it when the stack itself is misconfigured beyond what a release and renew fixes: a corrupted IP configuration, a leftover route or interface configuration from software that was uninstalled, an adapter that will not accept an address at all. Older guidance appends a log filename (netsh int ip reset resetlog.txt); current Windows does not require it, and the builder emits the short form.

Its consequence is the one to note before you run it: resetting TCP/IP to defaults can clear manually configured settings on your adapters — a static IP address, a manually set gateway, custom DNS servers — and put them back to “obtain automatically”. On a DHCP laptop that is exactly what you want. On a server or a workstation with a pinned address, write down the current configuration first, because you will be re-entering it after the reboot.

Both commands report success immediately and both are inert until you restart. Run them, restart, then test. Testing before the reboot tells you nothing.

The full reset, and how to run it properly

The full task emits all five commands in sequence, wrapped in comment lines:

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

This is the escalation, not the starting point. It is what you run when the targeted fixes have failed and you want everything back to a known state in one pass — a machine that has accumulated years of VPN clients and security agents, or one where you genuinely do not know which layer is broken.

Note what the sequence does and does not accomplish before the restart. The release, renew and flush run against the stack as it currently exists; the two resets only take effect after the reboot. So the tidy version is: run the block, restart, and then run ipconfig /renew and ipconfig /flushdns once more on the fresh stack before you decide whether it worked.

The comment lines in the output start with REM, which is a Command Prompt convention. Paste the block into cmd.exe and they are ignored as intended. Paste it into PowerShell and each REM line throws a “term is not recognized” error before the real commands run — the commands themselves are fine in either shell, but drop the comment lines if you are working in PowerShell.

Elevation

Both netsh resets require an administrator prompt and will fail with a permissions error without one. ipconfig /release and /renew also need elevation on a standard account. Only /flushdns and Clear-DnsClientCache generally run unelevated. The simplest approach is to open Windows Terminal or Command Prompt with Run as administrator for all of it — right-click the Start button and the elevated terminal is in that menu.

Confirming it worked

Each task has a different signal, and checking the right one saves you from repeating the whole sequence:

• After a flush — resolve the affected name again and confirm it now returns the address you expect. If it still returns the old one, the stale record is upstream, not local.
• After a release and renew — check the adapter has a real address from your network’s range rather than a 169.254.x.x autoconfiguration address, and that the gateway is populated.
• After a Winsock or TCP/IP reset — restart first, then try the thing that was failing. An application that could not connect while ping worked is the case that should now be fixed.
• After a full reset — restart, reconnect to Wi-Fi if prompted, then re-run the renew and flush before judging the outcome.

Because two of these commands are only reversible by reconfiguring by hand, capture the current state before you run them on anything that matters — the adapter’s IP configuration and DNS servers, and which security or VPN clients are installed. On a machine you administer for someone else, that note is the difference between a five-minute fix and an afternoon.

What these commands will not fix

Resetting the stack is a narrow tool, and reaching for it when the problem is somewhere else costs you a reboot and teaches you nothing:

• A driver problem. If the adapter is flagged in Device Manager or disappears intermittently, no netsh command helps — update or reinstall the driver.
• A proxy configuration. A wrong system proxy survives all of these. netsh winhttp reset proxy and the proxy settings in Windows Settings are the relevant controls.
• Wrong DNS servers handed out by the router. Flushing your cache re-fetches the same wrong answer from the same wrong server.
• Firewall or third-party security policy. A blocked application looks a lot like a broken stack, and none of these commands touch firewall rules.
• The network itself. If other devices on the same network have the same symptom, the problem is not on this machine.

Windows also ships a GUI equivalent under Settings, listed as Network reset, which removes and reinstalls the network adapters as well as resetting the stack. It is broader than these commands and always requires a restart, so treat it as the step after a full command-line reset rather than instead of one — and expect saved Wi-Fi networks and VPN connections to need setting up again afterwards.

The general rule holds throughout: work outward from the smallest change. Flush the cache first, then the lease, and only reset the stack when the cheap fixes have told you they are not enough.