Почему процесс "Система" прослушивает порт 443?
У меня проблемы с запуском моего сервера Apache, потому что порт 443 уже используется.
Оказывается, системный процесс (PID 4) использует порт 443. У меня не установлен IIS, services.msc показывает (как и ожидалось) ни сервер Exchange, ни работающие WWW-Services, ни IIS. Я понятия не имею, как выяснить, какой сервис использует этот порт, если не считать простого отключения каждого сервиса один за другим, и я даже не уверен, что это поможет.
Я был бы признателен, если бы кто-то мог указать мне, как я могу вернуть свой порт SSL, спасибо:)
PS: Конечно, "просто переключите Apache на другой порт для SSL" решит проблему невозможности запуска Apache. Но я все еще хотел бы знать, что так настойчиво связано с портированием порта 443.:)
К настоящему времени я выбрал "сложный маршрут" и отключил службы один за другим. Оказалось, что виновником стал сервис "Маршрутизация и RAS".
Спасибо всем за ценный вклад и новые инструменты в борьбе с "WTF моя система делает сейчас?"
16 ответов
Запустите следующее из командной строки с повышенными правами:
netstat -ab
Бьюсь об заклад, это Skype. Снимите флажок, показанный ниже, если он установлен.
Прежде всего, я отвечу на этот вопрос напрямую, и любой, кто его читает, может игнорировать любые ответы о сторонних приложениях сторонних разработчиков, использующих системный процесс.
Системный процесс указан как PID 4 в каждой современной системе Windows. Это для доступа в режиме ядра. Это исключает большинство сторонних веб-продуктов, таких как Apache.
С момента создания WinRM (Windows Remote Management) служба HTTP (%SystemRoot%\system32\drivers\http.sys) была стандартной частью Windows (Vista и более поздние версии / Server 2008 и более поздние версии). http.sys запускается под системным процессом (PID 4).
Другое разработанное Microsoft программное обеспечение может также использовать% SystemRoot% \ system32 \ drivers \ http.sys в системном процессе, например IIS, службы отчетов SQL и служба веб-развертывания Microsoft ( http://support.microsoft.com/kb/2597817)...
Порты WinRM 1.0 по умолчанию были:
HTTP = 80
HTTPS = 443
Порты WinRM 2.0 и выше по умолчанию:
HTTP = 5985
HTTPS = 5986
Проверьте с помощью следующих команд:
Winrm перечисляет winrm / config / listener
Winrm get http://schemas.microsoft.com/wbem/wsman/1/config
Действия по устранению неполадок:
Получите номер процесса порта, который вы ищете (443 в этом случае):
... с не сопоставленного диска Windows, чтобы избежать "Отказано в доступе":
netstat -aon | найти ":443"
Вывод должен выглядеть следующим образом для процесса System:
C:> netstat -ano | find ":443"
TCP 0.0.0.0:443 0.0.0.0:0 СЛУШАТЬ 4
TCP [::]: 443 [::]: 0 СЛУШАТЬ 4
Последний столбец - это PID (4).
Запуск списка задач, чтобы выяснить, что работает в процессе, оказывается бесполезным:
список задач /SVC /FI "PID eq 4"
список задач / м / ф "PID eq 4"Найдите в реестре службу HTTP: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo
Там будет список URL-адресов (с номерами портов), которые могут привести вас к тому, какое приложение работает и какие порты удерживают:
http: // +: 5985 / wsman / -> WinRM
https: // +: 5986 / wsman / -> WinRM
http: // +: 80 / Reports / -> Сервер отчетов SQL
http:// +:80/ReportServer/ -> Сервер отчетов SQL
https:// server_fqdn:443/Reports/ -> Сервер отчетов SQL
https:// server_fqdn:443/ReportsServer/ -> Сервер отчетов SQL
http://*:2869/ -> Служба протокола простого обнаружения служб (SSDPSRV)
http: // *: 5357 / -> Динамическое обнаружение веб-служб (WS-Discovery)
https: // *: 5358 / -> Динамическое обнаружение веб-служб (WS-Discovery)
Затем вы можете найти соответствующий сервис в системе и остановить его и увидеть, что требуемый порт освобожден, подтвердив с помощью другого netstat -aon | найти команду ":443".
У меня была проблема с тем, что порт 443 использовался "системой" с PID 4 на моей машине с Windows 7. Решением для меня было удалить "Входящее соединение" (VPN), существующее в папке сетевых подключений.
Кажется, я создал его и забыл удалить после использования...
Часто это служба агента хоста VMware (требуется для связи виртуального хоста с гостем) - vmware-hostd.exe,
Хороший способ узнать, какой подпроцесс svchost.exe запущен, - использовать Process Explorer от Sysinternals.
Я столкнулся с похожими проблемами при маршрутизации 443 запросов на мой WAS-сервер. Основываясь на рекомендациях в этом вопросе, вот что я сделал:
- Из повышенного cmd подскажите побежал
netstat -a -n -o | findstr 443 - Определил PID процесса прослушивания на 443
- Использовал Process Explorer для идентификации процесса по PID.
- В моем случае прослушивание приложения было
vmwarehostd.exe - Остановил сервер рабочей станции VMware из
services.msc, Перезапущен сервером WAS.
И все 443 запроса поступили к 443 с удовольствием.
PS: я уже удалил скайп, который был встроен в мою установку Windows 8. Служба маршрутизации и удаленного доступа была отключена на моей машине.
Если это процесс, запущенный службой, netstat -ab не поможет
В этом случае попробуйте netstat -ao | find /i "443" в командной строке администратора. Это даст вам такой вывод:
TCP 0.0.0.0:443 your_hostname:0 LISTENING PID
Затем введите tasklist | find /i "<PID>" в командной строке другого администратора.
В моем случае PID был 2912, и моя команда была:
tasklist | find /i "2912"
Вывод моей команды был:
vmware-hostd.exe 2912 Services 0 39 856 K
Вау, я даже забыл, что установил VMware для проверки работоспособности...
В моем случае это был DataManager из F5 Networks, который использует Tomcat 6 для обслуживания своих веб-страниц. Я забыл удалить это приложение. Плохое дизайнерское решение, если вы спросите меня.
Для меня после обновления Windows Server 2016 Apache 443 не мог запуститься с обычным перечисленным событием.
Я обнаружил, что виновником является служба Windows Sync Share (SyncShareSvc). Я отключил и смог запустить Apache.
В моем случае это был процесс DTC (координатор распределенных транзакций) для использования порта 443. В частности, я активировал WS-AT в DTC, и он использовал порт 443.
В общем, я понимаю, что когда системный процесс (PID 4) использует порт 443/HTTPS, это внутренний процесс Windows (в моем случае DTC, но я думаю, что это может быть и другой процесс), если это не веб-сайт IIS используй это.
С помощью netstat -ao | find ":443" Я обнаружил, что порт 443 используется PID 4, который был системным процессом. Это случилось со мной дважды на Windows Server 2012, и это было связано с одной из следующих причин:
- Служба IIS работала в списке "Служба публикации в Интернете", который я остановил.
- Функция рабочих папок установлена, поэтому я удалил ее.
Это может быть не решением для всех, но может помочь некоторым.
На моем Windows Server 2019 я решил это, запустив этот PS.
Stop-Service -Name KPSSVC
Он работал как процесс 4 (процесс SYSTEM) с правами сетевой службы. Бег
netstat -ab
не помогло. Отображается сообщение "Невозможно получить информацию о владельце".
После остановки службы netstat -aon | findstr ":443" больше не показывает запись. Обнаруживается литературным прекращением каждой службы одну за другой.
Служба прокси-сервера KDC (KPS) - служба прокси-сервера KDC работает на пограничных серверах для прокси-сообщений протокола Kerberos на контроллеры домена в корпоративной сети.
Еще одним виновником может быть Windows Admin Center (ServerManagementGateway).
Для меня это был агент McAfee EPO, прослушивающий порт 80. Мне пришлось пройти через несколько болезненных обручей, чтобы изменить его. https://kc.mcafee.com/corporate/index?page=content&id=KB67605
Я обнаружил, что при использовании функции VPN в Windows 8 (вероятно, то же самое для Windows 7) используется порт 443.
Кроме того, мой порт снова закрылся с помощью PMB.exe (Pando Media Booster).
Wireshark расскажет вам детали. http://www.wireshark.org/ Или TCP Monitor: http://www.itsamples.com/tcp-monitor.html
Это поможет
Если у вас есть какой-либо драйвер виртуальной локальной сети (например, OpenVM, VMware и т. Д.) - убедитесь, что вы "освободили" порт, прежде чем передавать его чему-то другому...
Просто быстрый побочный намек;)
У меня была такая же проблема при попытке установить обновление VMware. Я отследил это до скайпа. Новый клиент по умолчанию 443.