Denwer не работает! Хост http://test1.ru/ с localhost не открывается.

Прошу прощения за столь «вольный» заголовок, но именно в этом выражается суть проблемы. Кроме того, именно с такой формулировкой ко мне обращались некоторые «пострадавшие» пользователи denwer. На самом деле проблем может быть несколько, но в этой статье мы коснёмся самом популярной причины, по которой «denwer не работает». Если слова «командная строка» не вызывают у Вас нервной дрожи, то смело следуйте под кат и узнайте, как выявить причину именно на Вашей системе.

Вспомнить о самом частом случае, когда не открывается «test1.ru» с локального хоста мне пришлось после установки виртуальной машины «VMware». Всё дело в том, что в процессе её установки в систему добавляются виртуальные сетевые адаптеры и сетевые службы, которые обеспечивают доступ к сети из операционной системы, запущенной внутри виртуальной машины. Именно эти новые компоненты и мешают нормальной работе «Джентльменского Набора Web Разработчика» (Denwer). В моём случае не открывался «test1.ru», не работал phpmyadmin, да и знакомого с давних времён «Ура, заработало!» при обращении к localhost или 127.0.0.1 увидеть не удавалось. Впрочем – симптомы были точно такими же, как и у тех, кто обращался ко мне за помощью.

Процесс реанимации «Джентльменского Набора» довольно прост. Необходимо всего-навсего посмотреть, какая из программ использует тот же сетевой порт, что и Denwer (последнему по умолчанию требуются :80 и :443) и заставить конфликтующие программы пользоваться разными портами. Забегая вперёд скажу, что чаще всего виновниками становятся уже упомянутая VMware, Skype, TeamViewer или Tottent-клиент.

Не мудрствуя лукаво, открываем консоль и делаем запрос, кем же занят 443 порт: «netstat –ano |findstr :443». В ответе нам нужен ID процесса, который занял нужный нам порт. На скриншоте указан процесс «2284». Далее необходимо добиться более «распознаваемого» для человека идентификатора. Для этого в той же командной строке вводим: «tasklist |findstr 2248». В ответе видим, что это некий «httpd.exe». На момент, когда делались скриншоты, моя система не имела конфликтов по портам, а процесс «httpd.exe» принадлежит самому Denwer’у. В том же случае, если имеется конфликт, то по ID процесса отобразится название файла, принадлежащего другой программе/сервису. Начиная с «netstat» проделываем то же самое для 80 порта.

После выявления виновников, остаётся только перенастроить конфликтующую программу на другой порт. Можно, конечно, и сам Denwer попросить «подвинуться», но это сложнее. Итак, в моём случае был конфликт с виртуальной машиной VMware, порт которой мы и сменим. Для этого в окне VMware на закладке «Home» выбрать «Workstation Preferences» и перейти к разделу «Shared VMs». Именно там и прячется нужная нам настройка. Если VMware Workstation Server запущен, а поле указания порта недоступно для редактирования, то необходимо остановить VMs, указать новый порт VMware и снова включить VMs. В случае со Skype проблема решается аналогичным образом – в настройках надо снять галку «Использовать порты 80 и 443 в качестве входящих альтернативных».

После указанных манипуляций желательно перезапустить программу, которой указали новый порт. Остановку и новый запуск (или перезапуск) denwer выполнить строго необходимо. После выполнения этой нехитрой инструкции denwer успешно стартовал, хосты «127.0.0.1» и «test1.ru» успешно открылись, что говорит об отсутствии конфликта портов Denwer’а и VMware.

PS: кстати, если при запуске denwer не может занять свой порт, то выводится следующая ошибка: «[notice] Disabled use of AcceptEx() WinSock2 API (OS 10013). Only one usage of each socket address (protocol/network address/port) is normally permitted. make_sock: could not bind to address 127.0.0.1:443 no listening sockets available, shutting down. Unable to open logs.»