When you've executed taskkill /F /IM nginx.exe
and verified through netstat that port 80 is clear, yet still see the NGINX welcome page, you're likely dealing with one of these scenarios:
# Quick diagnosis commands:
netstat -ano | findstr :80
tasklist /FI "IMAGENAME eq nginx.exe"
sc queryex type= service state= all | findstr "NGINX"
NGINX on Windows often runs as a background service even when the main process appears killed. Try these service-specific commands:
# Stop and disable the service
sc stop nginx
sc config nginx start= disabled
# Nuclear option - delete the service entry
sc delete nginx
If the port remains occupied after killing NGINX, investigate these potential culprits:
- HTTP.sys (Windows' kernel-mode HTTP driver holding port 80)
- IIS or other web servers
- Docker containers with port mappings
# Check HTTP.sys reservations
netsh http show urlacl | findstr :80
# Release HTTP.sys hold (admin required)
netsh http delete urlacl url=http://+:80/
When standard methods fail, use Sysinternals Process Explorer to:
- Search for "nginx" in all process trees
- Identify child processes that may respawn the main process
- Kill the entire process tree
Check these common persistence points if NGINX keeps resurrecting:
# Scheduled tasks
schtasks /query /fo LIST | findstr /i "nginx"
# Startup entries
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
For thorough removal, run this batch script as Administrator:
@echo off
:: Stop and remove NGINX service
sc stop nginx >nul 2>&1
sc config nginx start= disabled >nul 2>&1
sc delete nginx >nul 2>&1
:: Kill all NGINX processes
taskkill /F /IM nginx.exe >nul 2>&1
:: Clear port 80 reservations
netsh http delete urlacl url=http://+:80/ >nul 2>&1
:: Verify cleanup
echo Verification:
tasklist | findstr "nginx"
netstat -ano | findstr ":80"
pause
When installing NGINX on Windows, consider:
- Using
nginx -s stop
before forceful termination - Running as console application (not service) during development
- Configuring alternative ports (8080, 8888) to avoid HTTP.sys conflicts
When you've executed taskkill /F /IM nginx.exe
and confirmed via netstat
that port 80 is clear, yet still see the NGINX welcome page loading in your browser, you're dealing with one of Windows' most frustrating process management quirks.
First, let's confirm what's really running:
:: Check all NGINX-related processes
tasklist /FI "IMAGENAME eq nginx.exe"
:: Alternative PowerShell method
Get-Process nginx -ErrorAction SilentlyContinue | Select-Object Id, ProcessName
Windows services often spawn child processes that standard termination misses. Try this comprehensive approach:
:: Stop NGINX service if installed
sc stop nginx
:: Kill all instances (including hidden)
taskkill /F /IM nginx.exe /T
:: Clean up residual network binding
netsh int ipv4 reset
netsh winsock reset
NGINX's architecture means master processes can respawn workers. Try this PowerShell sequence:
# Get all NGINX processes recursively
$nginxProcs = Get-CimInstance Win32_Process -Filter "name = 'nginx.exe'" | Select-Object ProcessId, ParentProcessId
# Build process tree and kill from bottom up
$nginxProcs | Sort-Object -Property ProcessId -Descending | ForEach-Object {
Stop-Process -Id $_.ProcessId -Force
Write-Host "Terminated PID $($_.ProcessId) (Parent: $($_.ParentProcessId))"
}
Sometimes the TCP stack maintains orphaned connections. Reset everything:
:: View all active TCP listeners
netstat -ano | findstr :80
:: For stubborn port binding (Admin CMD required)
netsh int ipv4 delete excludedportrange protocol=tcp startport=80 numberofports=1
Always use NGINX's native commands when possible:
:: Graceful shutdown (from NGINX directory)
nginx -s quit
:: Emergency stop
nginx -s stop
:: Then verify
tasklist /FI "IMAGENAME eq nginx.exe"
After termination attempts:
- Clear browser cache or test with curl:
curl -I http://localhost
- Check Windows Event Viewer for process errors
- Reboot if necessary (last resort)
Remember that Windows may cache DNS and network bindings temporarily. If the issue persists after all these steps, consider checking for malware or conflicting services that might be impersonating NGINX.