Хотя люди указывают на конкретные службы (например, «Служба агента веб-развертывания»), это не помогает устранить основную причину. Если вы просто отключите сервисы, которые вызывают проблему, скорее всего, в будущем он снова встанет в тупик в несколько ином виде. Так что стоит понять, что происходит не так, потому что это приводит к лучшему решению.
Эта проблема возникает, когда серверу приложений требуется полный контроль над портом 80. Это конфликтует с функцией Windows, которая предназначена для того, чтобы несколько процессов могли обрабатывать запросы на порту 80. Вполне возможно, что любое количество процессов будет получать запросы HTTP на порт. 80, потому что Windows имеет встроенный механизм отправки HTTP. Каждый процесс может сообщить Windows, какие URL он хочет обработать.
Однако, если сервер приложений полностью игнорирует это, то вы снова в менее гибком мире сокетов старой школы, где только один процесс может получать запросы, предназначенные для любого конкретного порта.
Это может быть хорошо - если вы действительно не хотите ничего, кроме определенного процесса, обрабатывающего HTTP-запрос на порту 80, тогда становится допустимым использование сервера приложений, который не поддерживает более гибкие механизмы, предлагаемые Windows. (И некоторые популярные серверы приложений имеют это ограничение. Например, AFAIK, Tomcat не в состоянии хорошо играть с другими и настаивает на том, чтобы порт 80 был для себя всем. Поэтому, если вы используете сервер приложений другого пользователя, это может быть непрактично для адаптировать его для использования предпочтительного механизма.)
Windows пытается приспособить такие негибкие сервисы, не привязывая свой механизм диспетчеризации к порту 80, пока что-то активно не попросит об этом. (Вот почему вы не обязательно увидите проблему изначально, но можете столкнуться с этой проблемой после какого-то обновления или изменения конфигурации.) Но полагаться на это не очень надежное решение - вы, по сути, доверяете удаче, что ничего пытается прослушать порт 80 до запуска сервера приложений. (Существуют различные причины, по которым процесс может спекулятивно пытаться зарегистрироваться для определенных URL-адресов на порту 80 и отключаться, если это не разрешено.)
Поэтому, если вы хотите, чтобы одна служба имела эксклюзивный доступ к порту 80, вам лучше сообщить об этом Windows. На самом деле недостаточно пытаться отключить все службы, которые могут попытаться использовать обычный механизм совместного использования портов, потому что трудно быть уверенным, что вы нашли все из них. (В частности, когда обновления Windows, кажется, изменяют то, что включено по умолчанию.) Вероятно, рекомендуется отключать те, о которых вы знаете, но лучше подходить к этому с обеих сторон: отключать ненужные службы, а также следить за тем, чтобы это не происходило. возможно для тех, кого вы не знали, чтобы сбить вас с толку.
По умолчанию HTTP.SYS(основной механизм отправки HTTP-портов с общим доступом в Windows) может прослушивать все адреса. Но вы можете сказать, что нет. На этой странице показан один из способов сделать это: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
Это относительно легкий способ сделать это, потому что он все еще позволяет прослушивать локальный хост для IPv6. Это просто освобождает порт 80 IPv4. Вы можете продвинуться дальше с более специализированной конфигурацией. (Вы могли бы даже HTTP.SYSполностью отключить , но это могло бы сломать вещи, используя порты кроме 80, таким образом, это может вызвать проблемы.)
Но что бы вы ни делали, суть в том, HTTP.SYSчтобы не пытаться прослушивать порт 80 с IP-адреса, который вас интересует. После того, как вы это сделали, вам не нужно беспокоиться об отключении служб, а также не нужно беспокоиться о других изменениях, вновь вызывающих проблему. Если вы убедились, что необходимая конечная точка фактически выходит за границы общего доступа к портам, то вы должны обнаружить, что системный процесс перестает привязываться к ней.