Почему процесс "Система" прослушивает порт 443?
У меня проблемы с запуском моего сервера Apache, потому что порт 443 уже используется.
Оказывается, системный процесс (PID 4) использует порт 443. У меня не установлен IIS, services.msc показывает (как и ожидалось) ни сервер Exchange, ни работающие WWW-Services, ни IIS. Я понятия не имею, как выяснить, какой сервис использует этот порт, если не считать простого отключения каждого сервиса один за другим, и я даже не уверен, что это поможет.
Я был бы признателен, если бы кто-то мог указать мне, как я могу вернуть свой порт SSL, спасибо:)
PS: Конечно, "просто переключите Apache на другой порт для SSL" решит проблему невозможности запуска Apache. Но я все еще хотел бы знать, что так настойчиво связано с портированием порта 443.:)
К настоящему времени я выбрал "сложный маршрут" и отключил службы один за другим. Оказалось, что виновником стал сервис "Маршрутизация и RAS".
Спасибо всем за ценный вклад и новые инструменты в борьбе с "WTF моя система делает сейчас?"
18 ответов
Запустите следующее из командной строки с повышенными правами:
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 для обслуживания своих веб-страниц. Я забыл удалить это приложение. Плохое дизайнерское решение, если вы спросите меня.
С помощью netstat -ao | find ":443" Я обнаружил, что порт 443 используется PID 4, который был системным процессом. Это случилось со мной дважды на Windows Server 2012, и это было связано с одной из следующих причин:
- Служба IIS работала в списке "Служба публикации в Интернете", который я остановил.
- Функция рабочих папок установлена, поэтому я удалил ее.
Это может быть не решением для всех, но может помочь некоторым.
В моем случае это был процесс DTC (координатор распределенных транзакций) для использования порта 443. В частности, я активировал WS-AT в DTC, и он использовал порт 443.
В общем, я понимаю, что когда системный процесс (PID 4) использует порт 443/HTTPS, это внутренний процесс Windows (в моем случае DTC, но я думаю, что это может быть и другой процесс), если это не веб-сайт IIS используй это.
Для меня после обновления Windows Server 2016 Apache 443 не мог запуститься с обычным перечисленным событием.
Я обнаружил, что виновником является служба Windows Sync Share (SyncShareSvc). Я отключил и смог запустить Apache.
Открытьservicesиз меню «Пуск» найдите и остановитеSecure Socket Tunneling Protocol Service. Основываясь на других ответах, я мог сделать вывод, что на этом порту находится базовая системная служба. Я думал, что это необходимо для VPN, но я мог бы использовать стороннее приложение с собственным приложением. Если это решило проблему, смело отключайте его. Это также приведет к тому, что его зависимости не будут выполняться, а именноRemote Access Connection ManagerиRouting and Remote Access.
Он работал после завершения обновления Windows 10 в апреле 2022 года, незадолго до этого я мог прекрасно использовать этот порт.
Вероятно, это происходит потому, что я использовал параметр «Разрешить входящие подключения» в окне сетевых подключений, чтобы настроить пользователей Windows (без их профилей) для создания пользователей для совместного использования файлов в локальной сети (Samba). Эту опцию оставили, по-моему, для создания VPN-сервера.
Я обнаружил, что при использовании функции VPN в Windows 8 (вероятно, то же самое для Windows 7) используется порт 443.
Кроме того, мой порт снова закрылся с помощью PMB.exe (Pando Media Booster).
Для меня это был агент McAfee EPO, прослушивающий порт 80. Мне пришлось пройти через несколько болезненных обручей, чтобы изменить его. https://kc.mcafee.com/corporate/index?page=content&id=KB67605
На моем Windows Server 2019 я решил это, запустив этот PS.
Stop-Service -Name KPSSVC
Он работал как процесс 4 (процесс SYSTEM) с правами сетевой службы. Бег
netstat -ab
не помогло. Отображается сообщение "Невозможно получить информацию о владельце".
После остановки службы netstat -aon | findstr ":443" больше не показывает запись. Обнаруживается литературным прекращением каждой службы одну за другой.
Служба прокси-сервера KDC (KPS) - служба прокси-сервера KDC работает на пограничных серверах для прокси-сообщений протокола Kerberos на контроллеры домена в корпоративной сети.
Еще одним виновником может быть Windows Admin Center (ServerManagementGateway).
Wireshark расскажет вам детали. http://www.wireshark.org/ Или TCP Monitor: http://www.itsamples.com/tcp-monitor.html
Это поможет
Если у вас есть какой-либо драйвер виртуальной локальной сети (например, OpenVM, VMware и т. Д.) - убедитесь, что вы "освободили" порт, прежде чем передавать его чему-то другому...
Просто быстрый побочный намек;)
У меня была такая же проблема при попытке установить обновление VMware. Я отследил это до скайпа. Новый клиент по умолчанию 443.