KB5066835 삭제 이후 재발 방지 설정과 개발 환경 정상화 체크리스트 (IIS / Docker / WSL

KB5066835를 삭제하면 localhost 자체는 대부분 복구되지만, 문제는 윈도우가 자동으로 다시 업데이트를 내려받아 재설치하려고 시도한다는 점입니다. 개발자 커뮤니티에서는 이를 ‘1회성 해결’이 아니라 ‘재발 방지’까지 포함해야 온전한 복구라고 보는 이유가 여기에 있습니다.

윈도우11 KB5066835 삭제로 localhost 오류 복구하는 방법

윈도우11 운영체제가 알아서 같은 패치를 다시 덮어씌우면 HTTP.sys가 또 막히게 되는데, 이 경우 원인을 찾기도 더 번거롭습니다. 그래서 패치를 삭제한 뒤에는 자동 재설치까지 막아두는 설정이 사실상 필수에 가깝습니다.

여기에 더해 IIS나 Docker, WSL 같은 로컬 개발 환경을 각각 다시 정상적으로 트래픽을 받아들일 수 있는 상태인지 점검하는 절차까지 확인하면 안정적으로 원상 복귀할 수 있습니다

KB5066835 업데이트 항목 삭제 명령어는 PowerShell에서도 간단하게 처리할 수 있어 CLI 사용 환경이 익숙한 개발자라면 아래 명령을 활용하는 편이 더 빠릅니다

wusa /uninstall /kb:5066835
wusa /uninstall /kb:5065789

문제가 심각한 환경에서는 두 패치를 모두 제거하고 재부팅하는 게 훨씬 확실하며, 이후 재발 방지를 위해 업데이트 지연 또는 차단을 걸어두면 안전합니다.

온라인 포럼과 GitHub 이슈에서도 가장 많이 공유되고 있는 방식이며 실제 효과도 검증된 상태라 우선적으로 고려할 만합니다.

아래 표는 각 개발 환경별로 정상화 여부를 체크할 수 있는 기준을 정리한 내용입니다

환경	정상화 확인 기준	추가 조치 필요 여부
IIS	http://localhost 바로 응답, AppPool 재시작 후 정상 로드	필요 시 appcmd로 단일 사이트 리바인드
Docker	포트 바인딩 재개, Backend 컨테이너 restart 이후 정상 호출	docker compose up –force-recreate 권장
WSL	127.0.0.1 연결 복원, wsl —shutdown 이후 재시작 시 바로 응답	간헐적 hang 시 hosts cache flush

이 과정을 마치고도 종종 발생하는 상황이 자동 업데이트 재설치 문제인데, 단순히 Windows Update 일시 중단 기능만으로는 완전 차단이 부족할 때가 있어 그룹 정책까지 걸어두면 훨씬 재발 확률을 줄일 수 있습니다.

특히 DevOps나 서버 사이드 작업을 많이 하는 환경일수록 의도치 않은 재설치가 업무 흐름을 재차 끊어버리는 사례가 빈번해 실제 현업에서는 이를 ‘안정화 세트’ 수준으로 묶어 적용하는 분위기입니다.

당장은 임시방편처럼 보일 수 있지만, 공식 핫픽스 전까지는 가장 현실적이고 안전한 대응 방식입니다

FAQ

PowerShell 삭제 이후 로그 확인이 필요한가요?

예, 삭제가 실패한 경우 wusa가 정상 비활성화하지 못한 상태가 남을 수 있어 Get-HotFix 로 해당 KB가 남아있는지 반드시 확인하는 것이 좋습니다

업데이트 차단을 언제까지 유지해야 하나요?

마이크로소프트가 문제를 공식 인정하고 핫픽스 번호를 공지할 때까지는 유지하는 것이 안전합니다. 커널 단 패치가 연계된 경우 수정까지 시간이 걸리는 편입니다

Docker 환경만 사용하는 경우도 IIS 점검이 필요한가요?

IIS가 백그라운드에 설치되어 있지 않더라도 HTTP.sys 수준에서 막히는 구조라 동일하게 점검 대상입니다. 커널이 원인이므로 도메인이 무엇이든 영향권에 포함됩니다

hosts 파일 수정은 효과가 있나요?

이번 오류는 단순 DNS 경로 문제나 name binding 이슈가 아니라 커널 내부의 HTTP.sys 응답 중단 문제라 hosts 수정만으로는 복구되지 않습니다