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

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

Буду вдячний, якщо хтось міг би вказати мені на те, як я можу повернути свій порт SSL, дякую :)

PS: Звичайно, "просто переключити Apache на інший порт для SSL" вирішить проблему неможливості запуску Apache. Але я все ж хотів би знати, що так наполегливо стосується портів 443. :)

Я вже брав один за одним "важкий маршрут" і відключав служби. Виявилося, що винуватцем була послуга "Маршрут та RAS".

Дякую всім за цінний внесок та нові інструменти в боротьбі з "WTF чи робить моя система зараз?".

Виконайте наступне з піднятого командного рядка:

netstat -ab

Б'юсь об заклад, що це Skype. Зніміть прапорець, показаний нижче, якщо його встановлено.

У мене виникла проблема, що порт 443 використовувався "системою" з PID 4 на моїй машині Windows 7. Для мене було рішення видалити "Вхідне з'єднання" (VPN), яке існувало в папці мережевих з'єднань.

Здається, я створив його та забув видалити після використання ...

По-перше, я відповім на це запитання безпосередньо, і кожен, хто читає це, може проігнорувати будь-які відповіді, що говорять про сторонні програми, що не є програмами Microsoft, що використовують системний процес.

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

2. З часу створення WinRM (віддалене управління Windows) послуга 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 / config
   

Етапи усунення несправностей:

Отримайте номер процесу, який шукаєте (443 у цьому випадку):

... з
невідкладеного накопичувача Windows, щоб уникнути "доступу заборонено": netstat -aon | find ": 443"
Вихід повинен виглядати наступним чином для системного процесу:
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:243 0.0.0.0grees LISTENING 4
TCP [::]: 443 [: :]: 0 СПИСОК 4
Остання колонка - PID (4).

5. Запуск списку завдань для з'ясування того, що працює в процесі, виявляється не корисним:
   tasklist / SVC / FI "PID eq 4" список
   завдань / m / FI "PID eq 4"
   

6. Подивіться в реєстр служби HTTP: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Параметри \ UrlAclInfo
   З'явиться список URL-адрес (з номерами портів), які можуть привести вас до того, що програма працює та тримає які порти:
   http : // +: 5985 / wsman / -> WinRM
   https: // +: 5986 / wsman / -> WinRM
   http: // +: 80 / Reports / -> SQL Server Reporting
   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" .

Часто це послуга VMware хост-агент (необхідна для зв'язку VM-хост-гость) - vmware-hostd.exe.

Хороший спосіб дізнатися, що працює підпроцес svchost.exe - це використовувати Провідник процесів Sysinternals .

У мене виникли подібні проблеми з маршрутизацією 443 запитів на мій сервер WAS. Виходячи з рекомендацій у цьому питанні, це я зробив:

1. З підвищеного cmd підскакувало netstat -a -n -o | findstr 443
2. Ідентифікували PID процесу прослуховування на 443
3. Використовується Провідник процесів для ідентифікації процесу з PID.
4. У моєму випадку програма прослуховування була vmwarehostd.exe
5. Зупинив сервер робочої станції 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, і це було пов’язано з однією з таких причин:

1. IIS був запущений, зазначений як "Всесвітня послуга публікації веб-сторінок" у службі, яку я зупинив.
2. Функція «Робочі папки» встановлена, тому я її видалив.

Це може бути не рішенням для всіх, але може допомогти деяким.

У моєму випадку процес DTC (Координатор розподілених транзакцій) використовував порт 443. Зокрема, я активував WS-AT в DTC, і він використовував 443 порт.

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

Для мене це був агент McAfee EPO, який слухав порт 80. Мені довелося пройти кілька болісних обручів, щоб змінити його. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

Для мене після оновлення Windows Server 2016 Apache 443 не міг почати з перелічених звичайних подій.

Винним я став службі "Windows Sync Share" (SyncShareSvc). Я відключився і зміг запустити Apache.

Я виявив, що для використання функцій VPN у Windows 8 (ймовірно, те саме для Windows 7) використовується порт 443.

Крім того, мій порт знову закрився програмою PMB.exe (Pando Media Booster).

Wireshark розповість вам подробиці. http://www.wireshark.org/ Або монітор TCP: http://www.itsamples.com/tcp-monitor.html

Це допоможе.

Якщо у вас є якийсь драйвер для віртуальної локальної мережі (наприклад, OpenVM, VMware тощо), переконайтеся, що ви "звільнили" порт, перш ніж надати його чомусь іншому ...

Просто швидкий побічний натяк;)

У мене були ті ж проблеми під час спроби встановити оновлення VMware. Я відстежив це до Skype. Новий клієнт за замовчуванням до 443.