Есть вещи, которые не меняются: законы физики, принципы термодинамики и то, что любой админ хотя бы раз за карьеру ломал IIS так, что потом приходилось смотреть на монитор взглядом побитого человека.
И вот ты сидишь, сервер пыхтит, сайты не открываются, а в голове только смутные флешбеки: «Ну я вроде немного что-то подкрутил… А что именно?…»
Ничего страшного. Сейчас устроим археологические раскопки твоего IIS, выкапывая там следы твоего же вчерашнего гения.
1. Уровень отрицания: проверяем, жив ли IIS вообще
Первым делом включаем внутреннего шамана и проверяем статус службы:
- IISADMIN
- W3SVC
- Windows Process Activation Service (WAS)
Если какое-то из них не запустилось — поздравляю, конфигурация уже настолько "успешно оптимизирована", что Windows решила саботировать тебе рабочий день.
Запускаем:
iisreset /start
Если он вместо запуска предлагает «идти нафиг с такими настройками», значит ломали сильно.
2. Уровень bargaining: проверка ApplicationHost.config
IIS — это не магия, это просто XML-файлик, который ты однажды решил тронуть, думая:
"Ну чего там, строк пару поправлю, я же знаю, что делаю".
Главный свиток:
C:\Windows\System32\inetsrv\config\applicationHost.config
Если там открывается что-то похожее на энтропию в чистом виде — да, это твоя работа.
Благо IIS хранит снимки. И вот здесь система показывает, что она тебя любит больше, чем ты заслуживаешь.
3. Уровень принятия: откатываемся из бэкапа, созданного не тобой
Папка автоспасения:
C:\inetpub\history
Внутри — автомагические версии конфигов, которые IIS создаёт при каждом чихе.
Выбираешь версию, когда «всё ещё работало», копируешь applicationHost.config и возвращаешь в config.
Именно в этот момент начинается то самое блаженное чувство, когда ты понимаешь: можно жить дальше.
4. Уровень перезагрузи-и-надейся
После восстановления обязательно:
iisreset
Если сайт ожил — ты красавчик.
Если нет — добро пожаловать в ад модулей и неправильных binding'ов.
5. Проверяем bindings, потому что IIS любит порт 80 сильнее, чем ты
Если кто-то — возможно ты — умудрился удалить или поменять binding на несуществующий IP или порт, IIS обидится и уйдёт в творческий отпуск.
Идём в IIS Manager → Site → Bindings
И проверяем:
- порт — тот ли?
- протокол — http/https верный?
- сертификат — живой или уже год как истёк вместе с твоей надеждой?
6. Разбор полётов в Web.config
Если у тебя много сайтов, где-то обязательно лежит web.config, написанный разработчиком под веществами или тобой в состоянии вдохновения.
Этот файл способен убить сайт даже быстрее, чем неправильный DNS A-запись.
Ищи:
- неправильные секции
- дублирующиеся handlers
- запрещённые конфиги уровня каталога
Самый верный тест:
Переименуй web.config во что-нибудь вроде web.config.broken_by_me.
Если сайт ожил — ну ты понял.
7. Легендарная кнопка “Rebuild config” — вручную
Если конфигурация настолько повреждена, что IIS начинает звучать как старый холодильник, всегда можно переустановить компоненты:
dism /online /disable-feature /featurename:IIS-WebServerRole
dism /online /enable-feature /featurename:IIS-WebServerRole
Это ядерный вариант, но иногда без него никак.
8. Профилактика: чтобы больше никогда так не страдать
А теперь самое важное: как жить, чтобы не лежать потом в серверной и не вспоминать, кем ты был и чем занимался.
Включи AppCmd бэкапы:
%windir%\system32\inetsrv\appcmd add backup "pre-experiment"
- Храни конфиги в Git. Да, даже IIS.
- Никогда не меняй настройки после 18:00.
- И вообще: если появился импульс “сейчас быстро подкручу” — остановись и выпей чай.
Восстановление конфигурации IIS, когда ты смутно помнишь только, что «точно что-то менял», — это ритуал очищения, духовного роста и, порой, слегка нервного смеха.
Но благодаря автобэкапам, истории версий и парочке админских трюков можно вернуть сервер к жизни быстрее, чем разработчик скажет: «У нас всё работало, значит виноват IIS!»
А сколько раз Вы ломали IIS? Напиши в комментариях.