Rozwiązywanie problemów z błędem HTTP 404 Nie znaleziono w IIS – Poradnik dla administratora systemu

Włącz szczegółowe komunikaty o błędach w systemie IIS i pobierz dokładny adres URL, o który zażądano, a następnie porównaj go z powiązaniami witryny, aby zidentyfikować, która witryna lub katalog wirtualny jest zamierzony. Ta pierwsza czynność często ujawnia, czy zasób jest brakujący, utracony, czy znajduje się w innej lokalizacji w Twojej infrastrukturze, pomagając szybko zlokalizować właściciela mapowania i poprawną ścieżkę.

Zidentyfikuj, czy błąd 404 wynika z brakującego pliku, błędnie skonfigurowanego katalogu wirtualnego, czy przekierowania, które prowadzi do nieistniejącej lokalizacji. W Menedżerze IIS przejrzyj ustawienia katalogu wirtualnego i zweryfikuj fizyczną ścieżkę na dysku, a następnie sprawdź uprawnienia do folderu, aby proces roboczy mógł kontynuować działanie w różnych witrynach. Jeśli masz kilka witryn, wypisz ich foldery główne i lokalizacje, które obsługują, aby zapobiec zamieszaniu między witrynami.

W przypadku aplikacji internetowych korzystających z trwałych odnośników upewnij się, że reguły przepisywania adresów URL lub mapowania obsługi nie maskują prawdziwego błędu 404 przyjazną stroną. Zaktualizuj reguły web.config lub przepisywania adresów URL, a następnie przetestuj ścieżkę internetową z przeglądarki i z dzienników po stronie serwera, aby potwierdzić, że wynikowy adres URL odnosi się do istniejącego pliku lub prawidłowej trasy.

Jeśli zasób nie jest obecny, utwórz symbol zastępczy lub przenieś plik do zamierzonej lokalizacji, lub skonfiguruj odpowiednią statyczną/ASP.NET trasę do obsługi zasobu. Dla każdej witryny prowadź rejestr właściciela i zamierzonej lokalizacji zawartości, aby przyspieszyć przyszłe identyfikacje. Używaj trwałych odnośników, aby sprawdzić, czy kanoniczne adresy URL mapują się na istniejące zasoby, zmniejszając przyszłe utracone błędy 404.

Następnie kontynuuj systematyczną weryfikację: sprawdź adres URL widoczny w Internecie, upewnij się, że nagłówki DNS i hosta wskazują na poprawną witrynę, i zmapuj trwałe odnośniki na rzeczywistą ścieżkę pliku. Jeśli nadal widzisz błąd 404, prześledź żądanie z dziennika żądań IIS, identyfikując, gdzie ścieżka jest tracona, i odpowiednio dostosuj, dokumentując zmiany dla właściciela i zespołu.

Analizuj dzienniki IIS pod kątem wzorców błędów 404 i nieudanych adresów URL

Wyeksportuj najnowsze dzienniki IIS i filtruj pod kątem odpowiedzi 404. Szukaj częstych ścieżek URL i pierwszego zaobserwowanego znacznika czasu, aby zidentyfikować powtarzające się problemy wpływające na osoby próbujące dotrzeć do Twojej witryny.

Wzorce błędów 404 ujawniają typowe przyczyny: brakujące zasoby, błędnie skonfigurowane wpisy katalogu wirtualnego i literówka w linku. Niektóre problemy wynikają z przekierowanej lub przeniesionej zawartości, a inne pochodzą z wewnętrznej nawigacji lub zewnętrznych odwołań. Zapisz wartość katalogu wirtualnego w notatkach, aby zapewnić spójność indeksowania. Zbuduj listę głównych sprawców i śledź liczby w czasie, aby odróżnić sporadyczne błędy od regularnie powtarzających się problemów.

Użyj pól odsyłacza i agenta użytkownika, aby ocenić, czy problem pochodzi z wyszukiwania, innych witryn, czy bezpośrednich wyszukiwań. Pomaga to nadać priorytet rozwiązywaniu przyczyny źródłowej i poprawie wrażeń użytkownika z mniejszym tarciem.

Wyeksportuj widok przyjazny dla tabel błędów 404, w tym ścieżkę URL, liczbę, pierwsze zaobserwowanie, odsyłacza i notatki. Ten format przyjazny do druku obsługuje aktualizowanie interesariuszy i utrzymywanie jednego źródła prawdy do optymalizacji ścieżek i indeksowania.

Ścieżka URL	Status	Liczba	Pierwsze Zaobserwowanie	Odsyłacz	Notatki
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Brakujący plik na dysku
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Przeniesiono do /docs/user-guide.html; zaktualizuj linki
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Błędna konfiguracja katalogu wirtualnego; zweryfikuj ścieżkę

Działania mające na celu rozwiązanie i zapobieganie błędom 404

W przypadku brakujących zasobów przywróć plik lub utwórz przekierowanie 301 do poprawnego adresu URL. W przypadku błędnie skonfigurowanych katalogów wirtualnych zweryfikuj ścieżkę katalogu wirtualnego w Menedżerze IIS, sprawdź applicationHost.config i upewnij się, że istnieje fizyczna ścieżka. W przypadku literówek popraw link, zaktualizuj zawartość o stronie i regularnie odświeżaj indeksy wyszukiwania wewnętrznego.

Wydrukuj podsumowany raport i udostępnij go zespołowi wsparcia. Aktualizuj bieżącą listę zmian, aby śledzić, co zadziałało, a co nie. W przypadku wielu częstych sprawców wdróż ukierunkowane przekierowania i usuń martwe linki, aby zmniejszyć przyszłe błędy.

Regularnie przeglądaj zebrane wzorce, optymalizując obsługę błędów 404 i testuj przekierowania w środowisku przejściowym przed zastosowaniem aktualizacji do produkcji. Takie podejście minimalizuje błędy i pomaga ludziom płynniej poruszać się po Twojej witrynie.

Zweryfikuj powiązania witryny, nagłówki hosta i katalogi wirtualne

Przejrzyj i popraw powiązania natychmiast: upewnij się, że nagłówek hosta, adres IP i port pasują do żądania klienta oraz że nazwa witryny odpowiada używanemu adresowi URL.

Kontrola powiązań

• Otwórz Menedżer IIS, przejdź do Witryny > [Twoja witryna] > Powiązania. Sprawdź, czy istnieje powiązanie dla http (i https, jeśli używane) z poprawnym adresem IP i portem. Jeśli wiele witryn współdzieli ten sam adres IP:port, dodaj nazwę hosta (nagłówek hosta), która pasuje do bieżącego adresu URL, aby poprawnie przekierowywać żądania.

• Przetestuj żądania z dokładnym nagłówkiem hosta: curl -I -H "Host: example.com" http://server/ lub użyj przeglądarki. Jeśli błąd 404 nadal występuje, powiązanie może być poprawne, ale żądana ścieżka jest obsługiwana przez inną witrynę.

• W przypadku https sprawdź, czy certyfikat pasuje do nazwy hosta w powiązaniu. Sprawdź podmiot i SAN-y i upewnij się, że powiązanie używa właściwego certyfikatu na porcie 443. Niezgodność może prowadzić do nieudanych żądań, które wyglądają jak brakujące zasoby.

• Sprawdź warstwy DNS i proxy: upewnij się, że przychodzące żądanie zawiera oczekiwany nagłówek hosta; błędna konfiguracja proxy może spowodować, że żądania trafią do niewłaściwej witryny, powodując błędy 404 dla prawidłowych ścieżek.

Katalogi wirtualne i konfiguracja ścieżki

1. Sprawdź, czy alias katalogu wirtualnego istnieje w witrynie; alias powinien pojawić się jako segment adresu URL (na przykład /files). Przejrzyj ścieżkę fizyczną w prawym okienku i upewnij się, że folder istnieje i jest dostępny dla tożsamości puli aplikacji.

2. Przekonwertuj na aplikację, gdy katalog powinien uruchamiać kod. Kliknij prawym przyciskiem myszy katalog wirtualny > Przekonwertuj na aplikację, wybierz poprawną pulę aplikacji i upewnij się, że tożsamość puli ma uprawnienia do odczytu ścieżki fizycznej.

3. Sprawdź dokumenty domyślne, jeśli opierasz się na adresach URL na poziomie katalogu; upewnij się, że istnieje prawidłowy dokument domyślny (index.html, default.aspx itp.) lub podaj wyraźną ścieżkę pliku w linkach.

4. Przejrzyj reguły web.config i przepisywanie adresów URL, które mogą przekierowywać do nieistniejącej ścieżki. Zła reguła może spowodować brak zasobu 404 dla w przeciwnym razie prawidłowych stron; dostosuj lub usuń konfliktowe reguły.

5. Sprawdź ważność uprawnień: przyznaj uprawnienia do odczytu/wykonania IIS_IUSRS i tożsamości puli aplikacji na ścieżce fizycznej i sprawdź, czy listy ACL NTFS zezwalają na dostęp dla oczekiwanego użytkownika. Brakujące uprawnienia często powodują błędy 404, które wyglądają tak, jakby zawartość zniknęła.

6. Przetestuj ponownie po zmianach: zażądaj problematycznego adresu URL i potwierdź 200 lub odpowiednie przekierowanie; jeśli przekierowanie zapętla się lub zasób pozostaje brakujący, przejrzyj reguły przepisywania i dzienniki uruchamiania w puli aplikacji.

Użyj podstawowego przeszukiwania, aby odkryć bieżący problem dotyczący brakujących stron spowodowanych powiązaniami lub katalogami wirtualnymi. Użyj polecenia grep w dziennikach IIS, aby znaleźć wpisy 404, aby znaleźć, które żądania się nie powiodły, a następnie rozwiąż przyczynę źródłową i przetestuj ponownie w świeżym przeszukiwaniu. Zapisz wyniki i udostępnij zwięzłe podsumowanie administratorom i współpracownikom na LinkedIn, aby wszyscy byli na bieżąco podczas rozwiązywania problemu.

Sprawdź ścieżki plików, fizyczne istnienie i uprawnienia do plików

Zweryfikuj fizyczną ścieżkę witryny w Menedżerze IIS i upewnij się, że ścieżka istnieje na dysku. W ustawieniach podstawowych witryny lub katalogu wirtualnego potwierdź, że folder, do którego kierujesz, zawiera oczekiwaną zawartość. Jeśli ścieżka się zmieniła, przywróć oryginalną lokalizację lub popraw mapowanie w przystawce, aby żądania kierowały się do właściwego folderu; w przeciwnym razie IIS nie ładuje nic i pojawiają się błędy 404.

Potwierdź, że plik faktycznie istnieje w systemie plików i że tożsamość puli aplikacji ma uprawnienia do przeglądania i odczytywania go. Użyj Eksploratora plików lub icacls, aby zweryfikować listy ACL w folderze i wszystkich folderach nadrzędnych. Przyznaj uprawnienia Odczyt i Wyświetlanie zawartości folderu oraz Przejdź do tożsamości puli aplikacji (na przykład IIS APPPOOL\YourAppPool) w katalogu głównym zawartości i plikach w nim zawartych. Jeśli uprawnienia są niepoprawne, IIS sygnalizuje odmowę dostępu, a silnik może zwrócić 404, nawet jeśli plik istnieje. Odpowiednio dostosuj listy ACL i przetestuj ponownie. Jeśli nie masz pewności, tymczasowo przypisz dostęp do odczytu znanemu użytkownikowi, aby potwierdzić, że plik się ładuje.

Sprawdź mapowanie typu MIME dla obsługiwanych rozszerzeń. Otwórz typ MIME dla witryny i upewnij się, że rozszerzenie ma powiązany typ MIME; brakujące mapowania często powodują błąd 404. W razie potrzeby dodaj typowe typy (.html, .css, .js, obrazy, czcionki) i sprawdź, czy wysyłany jest prawidłowy typ zawartości. Sprawdź również, czy adresy URL w stylu trwałych odnośników ładują się z poprawnego folderu; niezgodność między trasą trwałego odnośnika a ścieżką fizyczną może wywołać błąd 404 zarówno dla zasobów statycznych, jak i dynamicznych.

Przejrzyj ustawienia autoryzacji żądania w witrynie. W przystawce przejdź do reguł autoryzacji witryny i upewnij się, że tożsamość klienta może odczytać żądany folder. Jeśli reguła odrzucenia blokuje plik, silnik może zwrócić 404 dla niektórych ścieżek; usunięcie reguły lub jej zawężenie pomaga. Upewnij się, że anonimowe uwierzytelnianie jest włączone, jeśli polegasz na publicznym dostępie, i sprawdź ustawienia na poziomie domeny lub witryny, jeśli wiele witryn współdzieli ten sam katalog główny zawartości.

Włącz i sprawdź dzienniki i śledzenie. Włącz Śledzenie nieudanych żądań dla błędów 404 lub przejrzyj dzienniki IIS, aby zidentyfikować liczbę trafień i adres żądający. Poszukaj dokładnego adresu URL, zmapowanej ścieżki i ścieżki pliku z silnika; te dane identyfikacyjne pomagają zlokalizować źródło. Użyj informacji, aby przywrócić poprawną ścieżkę, naprawić kolejność ładowania i zapobiec frustrującym nawrotom. W witrynach internetowych sprawdź, czy profile domen i ścieżka fizyczna są zgodne; mała niezgodność może przerwać dostęp do wielu witryn. Po zmianach uruchom ponownie pulę aplikacji, aby zastosować nowe mapowania i uprawnienia. Jeśli konsekwentnie rozwiązujesz błąd 404, najpierw rozwiąż przyczynę źródłową, a następnie zweryfikuj ścieżkę użytkownika we wszystkich witrynach.

Przejrzyj reguły przepisywania adresów URL i konfiguracje błędów niestandardowych

Wyeksportuj bieżące reguły przepisywania adresów URL z IIS dla każdej witryny i porównaj je ze sprawdzoną bazą odniesienia, aby wskazać błędne konfiguracje, które prowadzą do wyników 404. Ujawnia to, czy problem pochodzi z przepisanego adresu URL, brakującego zasobu, czy niewłaściwej ścieżki błędu niestandardowego.

Co należy sprawdzić

Zlokalizuj reguły w web.config lub za pośrednictwem modułu przepisywania adresów URL dla każdej witryny. Przejrzyj wzorzec i warunki, które wyzwalają przepisanie lub przekierowanie, i sprawdź, czy docelowy adres URL prowadzi do istniejącego zasobu lub poprawnej strony HTML zdefiniowanej w błędach niestandardowych. Upewnij się, że wpis 404 jest zdefiniowany i że ścieżka używana przez stronę błędu istnieje w katalogu głównym witryny. Sprawdź konflikty między witrynami współdzielącymi pojedynczą pulę aplikacji, które mapują te same ścieżki.

Sprawdź kolejność oceny: pierwsza pasująca reguła zatrzymuje dalsze przetwarzanie. Poszukaj reguł przychodzących lub wychodzących, które mogą przechwycić błąd 404 przed uruchomieniem niestandardowego modułu obsługi błędów, i upewnij się, że w skonfigurowanej lokalizacji znajduje się strona rezerwowa 404. Przejrzyj wszelkie ustawienia globalne lub na poziomie witryny, które mogą przesłaniać konfigurację dla poszczególnych witryn.

Jak zastosować poprawki

Jeśli reguła jest błędnie skonfigurowana, dostosuj wzorzec dopasowania, akcję przepisywania i miejsce docelowe. Upewnij się, że brakujący zasób nie jest przepisywany na istniejącą ścieżkę, która zwraca odpowiedź inną niż 404. Zaktualizuj sekcję błędów niestandardowych, aby żądania 404 były kierowane do rzeczywistego pliku HTML i upewnij się, że plik został wdrożony z poprawnymi uprawnieniami. Po zmianach uruchom ponownie pulę aplikacji i przetestuj z różnych środowisk klienckich, aby potwierdzić spójne wyniki. Użyj dzienników serwera i danych śledzenia nieudanych żądań (FRT), aby zidentyfikować dokładną regułę i końcową stronę odpowiedzi.

Odtwarzaj błędy za pomocą ukierunkowanych testów i monitoruj odpowiedzi

Zalecenie: Odtwórz błąd 404 za pomocą ukierunkowanych testów i monitoruj odpowiedzi na wspólnym pulpicie nawigacyjnym. Rejestruj dowody w accesslog i przypisz właściciela dla każdego wzorca, aby przyspieszyć naprawę. Takie podejście pomaga kierownictwu zobaczyć bieżący wpływ i nadać priorytet poprawkom w różnych zakresach witryn.

Wyeksportuj ostatnie 200 wpisów 404 z accesslog dla witryny. Dla każdego wpisu zarejestruj czas, adres IP klienta, nazwę hosta, żądany adres URL, odsyłacza, agenta użytkownika, status i rozmiar odpowiedzi. Jeśli obserwujesz brakujące zasoby w powiązanych ścieżkach, wskazuje to na wzorce, a nie na odosobnione przypadki. Zbuduj zwięzłą listę testów z tych sygnałów, aby podjąć kolejne kroki.

Testuj wariacje ścieżek: żądaj znanych brakujących adresów URL z ukośnikiem na końcu i bez niego; zmień wielkość liter segmentów; dołącz lub usuń ciągi zapytań; porównaj odpowiedzi dla zasobów statycznych z trasami dynamicznymi. Dołącz zarówno metody GET, jak i HEAD, aby potwierdzić, że serwer zwraca 404 przed wystąpieniem niezamierzonych przekierowań lub przepisów.

Użyj Śledzenia Nieudanych Żądań (FRT), jeśli jest dostępne, i sprawdź krzyżowo z accesslog dla tych samych znaczników czasu. Te ślady wskazują, która reguła lub moduł zablokował zasób lub czy zasób naprawdę jest brakujący. Powiąż wyniki z metryką pulpitu nawigacyjnego: liczbą błędów 404 według trasy, hosta i konta. Ta doskonała korelacja przyspiesza dochodzenie i ujawnia bieżące hotspoty.

W przypadku zasobów za warstwą przepisywania lub routingu sprawdź powiązane web.config, reguły przepisywania adresów URL i wszelkie konfiguracje typu htaccess, które IIS może honorować za pośrednictwem modułów przepisywania. Jeśli błąd 404 wskazuje na problem z mapowaniem, dostosuj regułę lub ścieżkę pliku, a następnie uruchom ponownie testy, aby potwierdzić poprawkę przed przejściem do produkcji. W przypadkach, gdy błąd 404 wskazuje na zablokowany zasób, sprawdź listę blokad lub ograniczenia dostępu i upewnij się, że są one zgodne z zamierzonymi wzorcami dostępu.

Udokumentuj ustalenia na pulpicie nawigacyjnym i udostępnij podsumowanie właścicielowi witryny i kierownictwu. W razie potrzeby opublikuj spostrzeżenia na LinkedIn, aby zapewnić widoczność między zespołami. Proces powinien być powtarzalny: zapisz dane testowe, rejestruj odpowiedzi i dołącz powiązane dzienniki z accesslog, aby mogły zostać przejrzane przez właściciela konta lub zespół ds. bezpieczeństwa.

Sposoby na poprawę odporności: zbuduj małą uprząż testową, która iteruje przez listę testów, rejestruje kody stanu i oznacza skoki. Użyj tych sygnałów, aby podjąć działania w sprawie brakujących zasobów, zaktualizować inwentaryzacje zawartości i blokować głośne sondy po adresie IP tylko wtedy, gdy jest to uzasadnione. Zawsze utrzymuj bieżący zestaw testów w zgodzie z inwentarzem witryny i mapowaniami typów MIME, aby zapobiec regresjom.

Przed jakąkolwiek zmianą upewnij się, że masz zgodę właściciela i plan wycofywania zmian. Bieżący pulpit nawigacyjny monitorowania powinien wskazywać, czy wskaźnik 404 jest stabilny, rośnie, czy wraca do linii bazowej. Dobrze prowadzony reżim testowy przyspiesza reagowanie na incydenty i pomaga zespołowi zapewnić płynniejsze wrażenia użytkownika.