Почему процесс «Система» прослушивает порт 443?

45

У меня проблемы с запуском моего сервера Apache, потому что порт 443 уже используется.

Оказывается, системный процесс (PID 4) использует порт 443. У меня не установлен IIS, services.msc показывает (как и ожидалось) ни сервер Exchange, ни работающие WWW-Services, ни IIS. Я понятия не имею, как выяснить, какой сервис использует этот порт, если не считать простого отключения каждого сервиса один за другим, и я даже не уверен, что это поможет.

Я был бы признателен, если бы кто-то мог указать мне, как я могу вернуть свой порт SSL, спасибо :)

PS: Конечно, «просто переключите Apache на другой порт для SSL» решит проблему невозможности запуска Apache. Но я все еще хотел бы знать, что так настойчиво связано с портированием порта 443. :)


К настоящему времени я выбрал «сложный маршрут» и отключил службы один за другим. Оказалось, что виновником стал сервис «Маршрутизация и RAS».

Спасибо всем за ценный вклад и новые инструменты в борьбе с "WTF моя система делает сейчас?"

Корнелий
источник
Похожие страницы : superuser.com/questions/121901 Вы можете использовать любой из приведенных ответов, чтобы определить, какой сервис открывает порт 443.
Heavyyd
1
К сожалению, так как я не могу (или просто слишком глуп) выяснить, какая служба точно удерживает порт открытым, я не могу использовать «SC Config Servicename Type = own» для отставания Servicename. Как и было сказано, различные заклинания Netstat указывают на процесс System, как это делал TCPView. «Стеки», как и PE, по-видимому, не работают на Win7, и, поскольку я не смотрю на экземпляр svchost.exe, у меня нет столбца «Служба» на вкладке TCP / IP. Skype не виноват, и у меня не работает какое-либо другое программное обеспечение VoIP или P2P. Но другой вопрос, который вы связали, был мне поучительным; Спасибо.
Корнелиус
Спасибо за информацию! Для меня это была служба «Маршрутизация и удаленный доступ», которая также имела привязанный порт 443.
Кодлер
3
Человек, количество ответов, даже не пытаясь ответить на вопрос, невероятно. Как и количество дезинформации. Если PID 4 слушает, это так http.sys. Всегда. К счастью, уже есть ответ о том, как получить понимание .
Даниэль Б

Ответы:

19

Запустите следующее из командной строки с повышенными правами:

netstat -ab
Тонир Рот
источник
Я немного удивлен. Все остальное показывало просто «системный процесс» как виновника. Теперь эта команда утверждает, что это - svchost.exe, который содержит этот порт. : | Каким образом PE / «другие» вызовы netstat относят его к процессу System? (Хотя порт по-прежнему отображается как удерживаемый системой PID 4 / System.) Как я могу проверить дальше? :(
Корнелиус
не уверен, но запуск PE может быть повышен!
Тонир Рот
2
также следующее может дать вам более глубокое понимание wmic process> test.txt
tonyr roth
1
Я запустил Process Explorer в качестве администратора - и все же порт отображается, как заявлено "System"; там на самом деле гораздо больше доступной информации: | Теперь я думаю, что это будет что-то действительно глупое, что я невольно сделал;)
Корнелиус
4
Это не работает для меня, в соответствии с 0.0.0.0:443 Я просто получаю Не могу получить информацию о владельце .
MGOwen
33

Бьюсь об заклад, это Skype. Снимите флажок, показанный ниже, если он установлен.

Альтернативный текст

Nifle
источник
3
+1. Другие клиенты VoIP (и другое программное обеспечение, такое как приложения для передачи файлов P2P) будут прослушивать порты 80 и 443, если они не находят там ничего другого, хотя Skype является наиболее распространенным «нарушителем». Я не уверен, почему Skype будет отображаться как системный процесс, хотя.
Дэвид Спиллетт
К сожалению это не скайп; ни другие клиенты VoIP (ни один не установлен), ни P2P и т. д. и т. д. Я проверил это, и это не только «системный процесс», это «системный процесс» (PID 4)
Cornelius,
Как ни странно, у меня возникла та же проблема, что и у OP-443, которую взяла svchost ... и все же, отключение Skype исправило ее.
Blorgbeard
Была эта проблема. Следовал этим инструкциям и выяснил, что это был Skype: mydigitallife.info/…
saturdayplace
Просто для ясности: если ваш порт удерживается svchost и четко виден в Process Explorer, это была не та проблема, которая у меня была. Поэтому я настаивал на том, чтобы уточнить, что процесс с именем «Система», кажется, владеет портом.
Корнелиус
12

У меня была проблема с тем, что порт 443 использовался «системой» с PID 4 на моей машине с Windows 7. Решением для меня было удалить «Входящее соединение» (VPN), существующее в папке сетевых подключений.

Кажется, я создал его и забыл удалить после использования ...

doener
источник
1
Да, была такая же проблема на Windows 8.1.
Константин Переяслов
только что сделал это win7. Он перестал прослушивать TCP 443, хотя все еще прослушивает порт UDP 443, хотя это может быть достаточно.
Барлоп
1
У меня была эта проблема на Windows Server 2008 R2 x64. Мне потребовалось некоторое время, чтобы найти ваше сообщение, и я удивлен официальным ответом на этот вопрос, поскольку он на самом деле не отвечает на вопрос вообще. Спасибо!
simontemplar
Это сработало для меня, когда вместо удаления «Входящего соединения» (я не помню, как создать его снова, если оно мне понадобится снова), я снял флажок [_] Allow other computers to connect to this oneв разделе «Центр управления сетями и общим доступом», «Настройка адаптера», «Входящее соединение», «Свойства».
Александр Гельбух,
11

Прежде всего, я отвечу на этот вопрос напрямую, и любой, кто его читает, может игнорировать любые ответы о сторонних приложениях сторонних разработчиков, использующих системный процесс.

  1. System процесс указан как PID 4 на каждой современной системе Windows. Это для доступа в режиме ядра. Это исключает большинство сторонних веб-продуктов, таких как Apache.

  2. С момента создания WinRM (Windows Remote Management) служба HTTP ( % SystemRoot% \ system32 \ drivers \ http.sys ) была стандартной частью Windows (Vista и более поздние версии / Server 2008 и более поздние версии). http.sys запускается под системным процессом ( PID 4 ).

  3. Другое разработанное Microsoft программное обеспечение может также использовать% SystemRoot% \ system32 \ drivers \ http.sys в системном процессе, например IIS , службы отчетов SQL и служба веб-развертывания Microsoft ( http://support.microsoft.com/kb/2597817 ) ...

  4. Порты 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 / конфигурации

Действия по устранению неполадок:

Получите номер процесса порта, который вы ищете (443 в этом случае):

... с
неподключенного диска Windows, чтобы избежать «Отказано в доступе»: netstat -aon | find ": 443"
Вывод должен выглядеть следующим образом для системного процесса:
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 СЛУШАТЬ 4
TCP [::]: 443 [: :]: 0 СЛУШАТЬ 4
Последний столбец - это PID (4).

  1. Запуск списка задач, чтобы выяснить, что работает в процессе, оказывается бесполезным:
    список задач / SVC / FI "PID eq 4"
    список задач / m / FI "PID eq 4"

  2. Найдите в реестре службу 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" .

Кения Грэм
источник
Что касается пункта 6, как мы находим процесс прослушивания этих портов?
Галмок
8

Часто это служба агента хоста VMware (требуется для связи между хостом и гостем VM) - vmware-hostd.exe.

Хороший способ узнать, какой подпроцесс svchost.exe запущен, - использовать Process Explorer от Sysinternals .

Тони
источник
2
Если у вас действительно установлена ​​VMware Workstation, выберите «Правка» -> «Настройки» -> «Общие виртуальные машины». Возможно, у вас включен общий доступ к виртуальным машинам, а порт по умолчанию - 443. Вы можете отключить общий доступ, изменить порт и включить его обратно или просто оставить его отключенным, если он вам не нужен.
Гроностай
@gronostaj Большое спасибо, я просто потратил 3 часа, пытаясь найти это :(
Саймон Кирстен
7

Я столкнулся с похожими проблемами при маршрутизации 443 запросов на мой WAS-сервер. Основываясь на рекомендациях в этом вопросе, вот что я сделал:

  1. Из повышенного cmd подскажите побежал netstat -a -n -o | findstr 443
  2. Определил PID процесса прослушивания на 443
  3. Использовал Process Explorer для идентификации процесса по PID.
  4. В моем случае прослушивание приложения было vmwarehostd.exe
  5. Остановил сервер рабочей станции VMware с services.msc. Перезапущен сервером WAS.

И все 443 запроса поступили к 443 с удовольствием.

PS: я уже удалил скайп, который был встроен в мою установку Windows 8. Служба маршрутизации и удаленного доступа была отключена на моей машине.

Praveen
источник
3
-1 Его был PID 4, было намного сложнее. Вы пишете "Используется Process Explorer, чтобы идентифицировать процесс из pid." <- Ваш не был PID 4, например svchost или что-то в этом роде. Ваш был сторонним exe. Вы могли бы просто использовать диспетчер задач! Если вы еще не отображаете столбец, тогда просмотрите ... выберите столбец. Но вам повезло, что ваш PID не был PID 4. Я не знаю, может ли в этом помочь проводник процессов, а диспетчер задач - нет. Но, конечно, в вашем случае простой диспетчер задач сделал бы это.
Бароп
5

Если это процесс, запущенный службой, 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 для проверки работоспособности ...

elbedoit
источник
1
Для меня это был PID 4 ... будучи Системой.
Wouter
PID 4 обычно означает собственную службу Windows на основе Microsoft, что означает уровень ядра. Попробуйте остановить службы один за другим, и проверьте, решило ли это проблему. Отключите службу / удалите функцию, вызвавшую проблему @Wouter. Обычные услуги: Routing and RAS, ничего отметить , IISили World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Managerи подобное.
Эльбедойт
1

В моем случае это был DataManager из F5 Networks, который использует Tomcat 6 для обслуживания своих веб-страниц. Я забыл удалить это приложение. Плохое дизайнерское решение, если вы спросите меня.

Роман Зенка
источник
1

Используя netstat -ao | find ":443", я обнаружил, что порт 443 используется PID 4, который был системным процессом. Это случилось со мной дважды на Windows Server 2012, и это было связано с одной из следующих причин:

  1. Служба IIS работала в списке «Служба публикации в Интернете», который я остановил.
  2. Функция рабочих папок установлена, поэтому я удалил ее.

Это может быть не решением для всех, но может помочь некоторым.

anishpatel
источник
Этот ответ на самом деле не добавляет никакой новой информации, которой не было в ответах, представленных elbedoit или tonyr
Ramhound
1
Я специально добавил этот ответ, потому что удаление функции «Рабочие папки» сработало для меня, и, таким образом, это потенциальное решение проблемы в том виде, в котором она написана. Должен ли я представить эту информацию в комментарии вместо этого?
анишпатель
1
У меня возникла та же проблема, что и в вопросе, и ответ Тонира на меня не сработал. Ответ elbedoit не помогает, когда у вас есть PID 4 (как указано в вопросе); Вы собираетесь случайно остановить / перезапустить системные процессы, чтобы исправить проблему?
анишпатель
1
Ни в одном другом ответе не упоминается удаление функции «Рабочие папки», которая является решением вопроса. Я повторил информацию из других ответов, чтобы помочь другим с той же проблемой определить, может ли это решение работать на них (т. Е. Проверить, чтобы PID был равен 4). Если PID не 4, этот ответ определенно не поможет. Как этот ответ является более неполным, чем ответы Динера или Тонира? Пожалуйста, предложите, как я могу лучше донести свое решение.
Анишпатель
1
Да! Для меня это была также функция «Рабочие папки»! Большое спасибо за упоминание этого. Это действительно такой же правильный ответ, как упоминание Skype или любого другого сервиса ...
Wouter
1

В моем случае это был процесс DTC (координатор распределенных транзакций) для использования порта 443. В частности, я активировал WS-AT в DTC, и он использовал порт 443.

В общем, я понимаю, что когда системный процесс (PID 4) использует порт 443 / HTTPS, это внутренний процесс Windows (в моем случае DTC, но я думаю, что это может быть и другой процесс), если это не веб-сайт IIS используй это.

gurca
источник
0

Для меня после обновления Windows Server 2016 Apache 443 не мог запуститься с обычным перечисленным событием.

Я обнаружил, что виновником является служба Windows Sync Share (SyncShareSvc). Я отключил и смог запустить Apache.

JEC
источник
0

Я обнаружил, что при использовании функции VPN в Windows 8 (вероятно, то же самое для Windows 7) используется порт 443.

Кроме того, мой порт снова закрылся с помощью PMB.exe (Pando Media Booster).

user1788951
источник
-1

Wireshark расскажет вам детали. http://www.wireshark.org/ Или TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Это поможет

adeelx
источник
К сожалению, tcp-monitor не мог мне помочь; что касается wireshark - мне не удалось сгенерировать / перехватить пакеты, направленные на порт 443. :(
Cornelius,
1
Единственная оставшаяся опция - Process Explorer (sysinternals), которая покажет вам, как работает порт. Wireshark - один из лучших продуктов в этой линейке, но я не могу понять, почему он не работает для вас: s (Вы установили драйвер захвата WinPCAP?)
adeelx
Очень поздний ответ, извините. Но я не мог заставить что-либо войти, потому что там просто не было трафика, чтобы нюхать. По крайней мере, так я полагаю.
Корнелиус
-1 Wireshark не покажет вам ничего, что могло бы помочь определить, что находится на порте ... если только нет пакетов, идущих в порт. И даже тогда вы должны предоставить больше информации, например, что человек должен затем пропинговать IP и попытаться выяснить что это за IP.
Бароп
-1

Если у вас есть какой-либо драйвер виртуальной локальной сети (например, OpenVM, VMware и т. Д.) - убедитесь, что вы «освободили» порт, прежде чем передавать его чему-то другому ...

Просто быстрый побочный намек;)

Руслан Абузант
источник
-2

У меня была такая же проблема при попытке установить обновление VMware. Я отследил это до скайпа. Новый клиент по умолчанию 443.

Cal
источник
4
Это просто повторение существующего ответа. Пожалуйста, подтвердите существующие ответы, а не репост.
Ченмунка
@Chenmunka Возможно, он не читал это
FindOutIslamNow