Resolución de problemas de HTTP 404 No encontrado en IIS - Guía para administradores de sistemas

Habilite errores detallados en IIS y tome la URL solicitada exacta, luego compárela con las vinculaciones del sitio para identificar qué sitio o vdir está destinado. Esta primera acción a menudo revela si el recurso falta, se ha perdido o reside en una ubicación diferente en su infraestructura, ayudándolo a localizar rápidamente el propietario del mapeo y la ruta correcta.

Identifique si el 404 proviene de un archivo faltante, un directorio virtual mal configurado o una redirección que apunta a una ubicación inexistente. En el Administrador de IIS, inspeccione la configuración del vdir y verifique la ruta física en el disco, luego revise los permisos en la carpeta para que el proceso de trabajo pueda continuar en diferentes sitios. Si tiene varios sitios, liste sus carpetas raíz y las ubicaciones que sirven para evitar confusiones entre sitios.

Para aplicaciones web que usan enlaces permanentes, asegúrese de que las reglas de reescritura de URL o los mapeos de controladores no enmascaren un 404 real con una página amigable. Actualice el web.config o las reglas de reescritura de URL, luego pruebe la ruta de internet desde un navegador y desde los registros del lado del servidor para confirmar que la URL resultante se resuelve en un archivo real o una ruta válida.

Si el recurso no está presente, cree un marcador de posición o mueva el archivo a la ubicación destinada, o configure una ruta estática/ASP.NET adecuada para servir el recurso. Para cada sitio, mantenga un registro del propietario y la ubicación del contenido destinada para acelerar identificaciones futuras. Use enlaces permanentes para verificar que las URL canónicas se mapeen a recursos existentes, reduciendo futuros 404 perdidos.

Luego continúe con una verificación sistemática: verifique la URL orientada a internet, asegúrese de que DNS y los encabezados de host apunten al sitio correcto, y mapee los enlaces permanentes a una ruta de archivo real. Si aún ve un 404, rastree la solicitud desde el registro de solicitudes de IIS, identificando dónde se pierde la ruta, y ajuste en consecuencia, documentando los cambios para el propietario y el equipo.

Analice los registros de IIS en busca de patrones de 404 y URL fallidas

Exporte los registros más recientes de IIS y filtre las respuestas 404. Busque rutas de URL frecuentes y la marca de tiempo de la primera observación para identificar problemas recurrentes que afectan a las personas que intentan acceder a su sitio.

Los patrones en los 404 revelan causas comunes: recursos faltantes, entradas de vdir mal configuradas y un error tipográfico en un enlace. Algunos problemas provienen de contenido redirigido o movido, mientras que otros surgen de la navegación interna o referencias externas. Registre el valor de vdir en sus notas para mantener la indexación consistente. Construya una lista de los principales infractores y rastree los conteos con el tiempo para distinguir fallos ocasionales de problemas que se repiten regularmente.

Use los campos de referente y agente de usuario para evaluar si el problema proviene de búsquedas, otros sitios o búsquedas directas. Esto le ayuda a priorizar la resolución de la causa raíz y mejorar la experiencia del usuario con menos fricciones.

Exporte una vista compatible con tablas de 404, incluyendo ruta de URL, conteo, primera observada, referente y notas. Este formato compatible con impresión soporta la actualización de las partes interesadas y mantiene una sola fuente de verdad para optimizar rutas e indexación.

Ruta de URL	Estado	Conteo	PrimeraObservada	Referente	Notas
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Archivo faltante en disco
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Movido a /docs/user-guide.html; actualice enlaces
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Mal configuración de VDir; verifique ruta

Acciones para resolver y prevenir 404

Para recursos faltantes, restaure el archivo o cree una redirección 301 a la URL correcta. Para vdirs mal configurados, verifique la ruta de vdir en el Administrador de IIS, revise applicationHost.config y asegúrese de que exista una ruta física. Para errores tipográficos, corrija el enlace, actualice el contenido sobre la página y refresque los índices de búsqueda internos regularmente.

Imprima un informe resumido y compártalo con el equipo de soporte. Mantenga actualizada una lista en ejecución de cambios para rastrear qué funcionó y qué no. Para múltiples infractores frecuentes, implemente redirecciones dirigidas y elimine enlaces muertos para reducir errores futuros.

Revise regularmente los patrones que recopila, optimizando el manejo de 404, y pruebe redirecciones en un entorno de staging antes de aplicar actualizaciones a producción. Este enfoque minimiza errores y ayuda a las personas a tener una experiencia más fluida al navegar por su sitio.

Verifique vinculaciones de sitio, encabezados de host y directorios virtuales

Revise y corrija las vinculaciones inmediatamente: asegúrese de que el encabezado de host, IP y puerto coincidan con la solicitud del cliente y que el nombre del sitio corresponda a la URL en uso.

Verificaciones de vinculación

• Abra el Administrador de IIS, navegue a Sitios > [su sitio] > Vinculaciones. Verifique que haya una vinculación para http (y https si se usa) con la IP y puerto correctos. Si varios sitios comparten la misma IP:puerto, agregue un nombre de host (encabezado de host) que coincida con la URL actual para enrutar las solicitudes correctamente.

• Pruebe solicitudes con el encabezado de host exacto: curl -I -H "Host: example.com" http://server/ o use un navegador. Si el 404 persiste, la vinculación puede ser correcta pero la ruta solicitada es manejada por otro sitio.

• Para https, verifique que el certificado coincida con el nombre de host en la vinculación. Revise el sujeto y SAN, y asegúrese de que la vinculación use el certificado correcto en el puerto 443. Un desajuste puede llevar a solicitudes fallidas que parezcan recursos faltantes.

• Inspeccione DNS y capas de proxy: asegúrese de que la solicitud entrante lleve el encabezado de host esperado; una mal configuración de proxy puede causar que las solicitudes aterricen en el sitio equivocado, generando 404 para rutas válidas.

Directorios virtuales y configuración de rutas

1. Verifique que el alias del directorio virtual exista bajo el sitio; el alias debe aparecer como un segmento de URL (por ejemplo /files). Revise la ruta física en el panel derecho y confirme que la carpeta existe y es accesible por la identidad del grupo de aplicaciones.

2. Convierta a Aplicación cuando el directorio deba ejecutar código. Haga clic derecho en el directorio virtual > Convertir a Aplicación, seleccione el Grupo de Aplicaciones correcto y asegúrese de que la identidad del grupo tenga permisos de lectura en la ruta física.

3. Verifique documentos predeterminados si depende de URL a nivel de directorio; asegúrese de que haya un documento predeterminado válido (index.html, default.aspx, etc.) o proporcione una ruta de archivo explícita en sus enlaces.

4. Revise las reglas de web.config y las reescrituras de URL que podrían redirigir a una ruta inexistente. Una regla mala puede producir un 404 de recurso faltante para páginas válidas de otro modo; ajuste o elimine reglas en conflicto.

5. Valide permisos: otorgue lectura/ejecución a IIS_IUSRS y la identidad del grupo de aplicaciones en la ruta física, y verifique que las ACL de NTFS permitan el acceso para el usuario esperado. Los permisos faltantes a menudo causan 404 que parecen que el contenido se ha ido.

6. Pruebe nuevamente después de los cambios: solicite la URL problemática y confirme un 200 o redirección adecuada; si hay un bucle de redirección o un recurso sigue faltando, revise las reglas de reescritura y los registros de inicio en el grupo de aplicaciones.

Use un rastreo básico para descubrir el problema actual sobre páginas faltantes causadas por vinculaciones o directorios virtuales. Busque en los registros de IIS las entradas 404 para encontrar qué solicitudes están fallando, luego aborde la causa raíz y pruebe nuevamente en un rastreo fresco. Guarde los resultados y comparta un resumen conciso con administradores y colegas en LinkedIn para mantener a todos alineados mientras maneja el problema.

Valide rutas de archivo, existencia física y permisos de archivo

Verifique la Ruta Física del sitio en el Administrador de IIS y asegúrese de que la ruta exista en el disco. En Configuraciones Básicas para el sitio o directorio virtual, confirme que la carpeta a la que apunta contiene el contenido que espera. Si la ruta cambió, restaure la ubicación original o corrija el mapeo en el complemento para que las solicitudes aborden la carpeta correcta; de lo contrario, IIS no carga nada y ve 404.

Confirme que el archivo existe fieldente en el sistema de archivos y que la identidad del grupo de aplicaciones tiene derechos para recorrerlo y leerlo. Use el Explorador de Archivos o icacls para verificar las ACL en la carpeta y todas las carpetas padre. Otorgue Lectura y Listar Contenido de Carpeta y Recorrer a la identidad del grupo de aplicaciones (por ejemplo IIS APPPOOLYourAppPool) en la raíz del contenido y los archivos dentro. Si los permisos son incorrectos, IIS indica denegación de acceso y el motor puede devolver 404 incluso cuando el archivo existe. Ajuste las ACL apropiadamente y vuelva a probar. Si no está seguro, asigne temporalmente acceso de lectura a un usuario conocido para confirmar que el archivo se carga.

Verifique el mapeo de tipos MIME para las extensiones que sirve. Abra el tipo MIME para el sitio y asegúrese de que la extensión tenga un tipo MIME asociado; los mapeos faltantes a menudo generan un 404. Si es necesario, agregue tipos comunes (.html, .css, .js, imágenes, fuentes) y verifique que se envíe el content-type correcto. También verifique que las URL de estilo permalink se carguen desde la carpeta correcta; un desajuste entre la ruta permalink y la ruta física puede activar 404 para activos estáticos y dinámicos.

Revise la configuración de autorización de solicitudes del sitio. En el complemento, navegue a las Reglas de Autorización del sitio y asegúrese de que la identidad del cliente esté permitida para leer la carpeta solicitada. Si una regla de denegación bloquea el archivo, el motor puede devolver 404 para algunas rutas; eliminar la regla o estrecharla ayuda. Confirme que la Autenticación Anónima esté habilitada si depende del acceso público, y verifique configuraciones a nivel de dominio o sitio si varios sitios comparten la misma raíz de contenido.

Habilite y revise registros y rastreo. Active el Rastreo de Solicitudes Fallidas para errores 404 o revise los registros de IIS para identificar el número de accesos y la dirección solicitante. Busque la URL exacta, la ruta mapeada y la ruta de archivo del motor; estos datos de identificación ayudan a localizar la fuente. Use la información para restaurar una ruta correcta, corregir el orden de carga y prevenir reincidencias frustrantes. En sitios orientados a internet, verifique que los perfiles de dominio y la ruta física se alineen; un pequeño desajuste puede romper el acceso para múltiples sitios. Después de los cambios, recicle el grupo de aplicaciones para aplicar los nuevos mapeos y permisos. Si está abordando un 404 de manera consistente, aborde primero la causa raíz y luego verifique el viaje del usuario en todos los sitios.

Revise las reglas de Reescritura de URL y configuraciones de Errores Personalizados

Exporte las reglas actuales de Reescritura de URL de IIS para cada sitio y compárelas con una línea base conocida buena para identificar mal configuraciones que llevan a resultados 404. Esto revelará si el problema se origina en una URL reescrita, un recurso faltante o una ruta de error personalizado inadecuada.

Qué inspeccionar

Localice las reglas en web.config o a través del módulo de Reescritura de URL para cada sitio. Revise el patrón y las condiciones que activan una reescritura o redirección, y verifique que la URL de destino apunte a un recurso existente o a una página html adecuada definida en Errores Personalizados. Confirme que la entrada 404 esté definida y que la ruta usada por la página de error exista bajo la raíz del sitio. Verifique conflictos entre sitios que comparten un solo grupo de aplicaciones que mapean las mismas rutas.

Audite el orden de evaluación: la primera regla coincidente detiene el procesamiento adicional. Busque reglas de entrada o salida que puedan capturar un 404 antes de que se ejecute el manejador de errores personalizado, y asegúrese de que haya una página 404 de respaldo en la ubicación configurada. Revise cualquier configuración global o a nivel de sitio que pueda anular la configuración por sitio.

Cómo aplicar correcciones

Si una regla está mal configurada, ajuste el patrón de coincidencia, la acción de reescritura y el destino. Asegúrese de que un recurso faltante no se reescriba a una ruta existente que devuelva una respuesta no 404. Actualice la sección de Errores Personalizados para que las solicitudes 404 se enruten a un archivo html real y verifique que el archivo esté desplegado con permisos correctos. Después de los cambios, recicle el grupo de aplicaciones y pruebe desde diferentes entornos de cliente para confirmar resultados consistentes. Use los registros del servidor y los datos de Rastreo de Solicitudes Fallidas (FRT) para identificar la regla exacta y la página de respuesta final.

Reproduzca fallos con pruebas dirigidas y monitoree respuestas

Recomendación: Reproduzca el 404 con pruebas dirigidas y monitoree respuestas en un tablero compartido. Capture evidencia en el accesslog y asigne un propietario para cada patrón para acelerar la remediación. Este enfoque ayuda a la gerencia a ver el impacto actual y priorizar correcciones en todos los ámbitos del sitio.

Exporte las últimas 200 entradas 404 del accesslog para el sitio. Para cada entrada, registre tiempo, IP del cliente, nombre de host, URL solicitada, referente, agente de usuario, estado y tamaño de respuesta. Si observa activos faltantes bajo rutas relacionadas, esto indica patrones en lugar de casos aislados. Construya una lista de pruebas concisa a partir de estas señales para dar los siguientes pasos.

Pruebe variaciones de rutas: solicite URL conocidas como faltantes con y sin barra final; cambie el caso de segmentos; agregue o elimine cadenas de consulta; compare respuestas para activos estáticos contra rutas dinámicas. Incluya tanto métodos GET como HEAD para confirmar que el servidor devuelve 404 antes de cualquier redirección o reescritura no intencional.

Use Rastreo de Solicitudes Fallidas (FRT) cuando esté disponible, y verifique con el accesslog para las mismas marcas de tiempo. Estos rastreos indican qué regla o módulo bloqueó el recurso, o si el recurso fieldente falta. Vincule resultados a una métrica de tablero: conteo de 404 por ruta, por host y por cuenta. Esta excelente correlación acelera la investigación y revela puntos calientes actuales.

Para recursos detrás de una capa de reescritura o enrutamiento, verifique web.config relacionado, reglas de Reescritura de URL y cualquier configuración similar a htaccess que IIS pueda honrar a través de módulos de reescritura. Si el 404 indica un problema de mapeo, ajuste la regla o ruta de archivo, luego vuelva a ejecutar las pruebas para confirmar la corrección antes de pasar a producción. En casos donde el 404 apunta a un recurso bloqueado, verifique la lista de bloqueo o restricciones de acceso y asegúrese de que se alineen con los patrones de acceso destinados.

Documente hallazgos en el tablero y comparta el resumen con el propietario del sitio y la gerencia. Si es necesario, publique insights en LinkedIn para visibilidad entre equipos. El proceso debe ser repetible: guarde las entradas de prueba, capture respuestas y adjunte registros relacionados del accesslog para que puedan ser revisados por el propietario de la cuenta o el equipo de seguridad.

Maneras de mejorar la resiliencia: construya un arnés de prueba pequeño que itere a través de la lista de pruebas, registre códigos de estado y marque picos. Use estas señales para actuar sobre activos faltantes, actualizar inventarios de contenido y bloquear sondas ruidosas por IP solo cuando sea justificado. Siempre mantenga la suite de pruebas actual alineada con el inventario del sitio y los mapeos de tipos MIME para prevenir regresiones.

Antes de cualquier cambio, asegúrese de tener la aprobación del propietario y un plan de rollback. El tablero de monitoreo continuo debe indicar si la tasa de 404 es estable, creciente o regresando a la línea base. Un régimen de pruebas bien ejecutado acelera la respuesta a incidentes y ayuda al equipo a entregar una experiencia de usuario más fluida.