When Ollama refuses to start on Windows, the obvious assumption is that another app is already using its default port. That was my first thought too when ollama serve failed with Error: listen tcp 127.0.0.1:11434: bind: An attempt was made to access a socket in a way forbidden by its access permissions. On top of that, even ollama list returned a WSARECV connection-forcibly-closed error, which made the problem feel less like a simple startup issue and more like something deeper in the networking stack.
What made this case especially confusing was that port 11434 did not appear to belong to a normal user application. Instead, the listener seemed to be owned by svchost.exe, specifically the IP Helper service (iphlpsvc). That pointed away from Ollama itself and toward a Windows networking feature. At first glance, it looked like a system-level service was somehow blocking Ollama from binding to its own loopback port.
After working through the usual diagnostics, the real cause turned out to be surprisingly specific: a persistent netsh interface portproxy rule forwarding 0.0.0.0:11434 to a WSL address, 172.26.221.10:11434. Because Windows implements that forwarding through iphlpsvc, the IP Helper service showed up as the owner of the port. Once that rule was removed or moved to another local port, Ollama started normally again. What follows is the step-by-step story of how that was discovered and fixed.
When Port 11434 Was Already Taken on Windows
The first sign of trouble was simple enough. Running ollama serve on Windows failed immediately with the bind error on port 11434, which is Ollama’s default listening port. Even worse, related commands like ollama list did not behave normally either, instead failing with a socket receive error indicating that the connection had been forcibly closed. That suggested the port was not just busy, but being actively handled by something else.
The natural next step was to find out what was holding the port. Running netstat -aon | findstr :11434 showed that the port was indeed in use, and it pointed to PID 4588. Looking up that PID with tasklist /FI "PID eq 4588" showed svchost.exe, which is not very informative by itself because many Windows services share that process host. To narrow it down, tasklist /svc /fi "imagename eq svchost.exe" was used, and that eventually showed that PID 4588 was hosting iphlpsvc, the IP Helper service.
That result changed the direction of the investigation. There was no normal Ollama Windows service registered under a name like Ollama, and Get-Service -Name Ollama confirmed that nothing obvious was running as a background service under that label. In other words, the port was not blocked by an old Ollama process or by some stray user-space app. It was being bound by a Windows networking service, which explained why the error felt so stubborn and why restarting Ollama alone accomplished nothing.
Finding the Hidden Portproxy Behind Ollama
At that point, the first instinct was to try freeing the port directly. Stopping the IP Helper service with Stop-Service iphlpsvc did release the port for a moment, which seemed promising. But that was only temporary, and disabling the service permanently was not a realistic fix because iphlpsvc is important for normal Windows networking behavior. Killing the hosting svchost process with taskkill /PID 4588 /F had the same short-lived effect: the listener disappeared, then came right back as Windows recreated it.
Those failed attempts revealed an important clue. Something was not merely listening on port 11434; something was causing Windows to recreate that listener whenever the service restarted. A check for an http.sys reservation turned up nothing, so the culprit was not a URL ACL or a standard HTTP namespace reservation. The missing piece finally appeared after running netsh interface portproxy show all, which listed a forwarding rule from 0.0.0.0:11434 to 172.26.221.10:11434, the WSL address.
That explained everything. A netsh interface portproxy rule creates a TCP forwarding listener managed by the IP Helper service, so iphlpsvc appearing as the owner of port 11434 was expected behavior. In this case, Windows was forwarding all traffic arriving on local port 11434 to the WSL instance, and that forwarding rule persisted independently of Ollama. The fix was straightforward once the rule was identified: delete it if it was no longer needed, move it to another local port such as 11534, or leave it in place and configure Ollama to listen somewhere else with setx OLLAMA_HOST "127.0.0.1:11500".
The cleanest solution was to remove the conflicting rule:
netsh interface portproxy delete listenport=11434 listenaddress=0.0.0.0Or, in some setups:
netsh interface portproxy delete listenport=11434 listenaddress=*After that, netstat -aon | findstr :11434 returned nothing, ollama serve started normally, and ollama list worked again. If the WSL forwarding still mattered, the better option was to recreate it on a different local port:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11534 connectaddress=172.26.221.10 connectport=11434The root cause of this Ollama startup failure on Windows was not Ollama at all, but a hidden netsh portproxy rule silently occupying port 11434 through the IP Helper service. That is why the port looked like it belonged to iphlpsvc, why stopping the service only helped briefly, and why the listener kept coming back. Once the proxy entry was removed or moved, the problem disappeared immediately.
The main lesson here is that when a port appears to be owned by svchost.exe or iphlpsvc, it is worth checking netsh interface portproxy show all before digging too far into application-level debugging. In environments that mix Windows tools with WSL networking, these forwarding rules can linger and create confusing conflicts later. A quick check can save a lot of time.
If you run into the same error, the checklist is simple: confirm the port is in use, identify the owning PID, inspect the services inside that svchost, check for a portproxy rule, and then delete or relocate the conflicting entry. Once port 11434 is truly free, Ollama should bind normally and run without the “forbidden by its access permissions” error.