{"id":616,"date":"2025-10-21T18:33:41","date_gmt":"2025-10-21T23:33:41","guid":{"rendered":"https:\/\/blog.pirulug.com\/?p=616"},"modified":"2025-10-21T18:33:41","modified_gmt":"2025-10-21T23:33:41","slug":"como-solucionar-el-error-misdirected-request-en-hestiacp-vps-nginx-apache","status":"publish","type":"post","link":"https:\/\/blog.pirulug.com\/?p=616","title":{"rendered":"C\u00f3mo solucionar el error \u00abMisdirected Request\u00bb en HestiaCP (VPS): NGINX + Apache"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>Contenido:<\/strong><br>El error <strong>421 Misdirected Request<\/strong> aparece cuando un cliente (por ejemplo un navegador) realiza una conexi\u00f3n HTTPS en la que el nombre de host solicitado no coincide con el nombre de host que el servidor presenta en la negociaci\u00f3n TLS (con SNI). En entornos donde NGINX act\u00faa como proxy frente a Apache (como en HestiaCP + NGINX + Apache), este problema puede emerger tras actualizaciones de Apache u otros componentes. <a href=\"https:\/\/forum.hestiacp.com\/t\/nginx-apache-ssl-421-misdirected-request\/19502?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">cPanel Support+3Hestia Control Panel &#8211; Discourse+3Hestia Control Panel &#8211; Discourse+3<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. \u00bfQu\u00e9 est\u00e1 ocurriendo?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>En la negociaci\u00f3n TLS, el cliente env\u00eda la extensi\u00f3n <strong>Server Name Indication (SNI)<\/strong> con el nombre de host que desea alcanzar. El servidor debe presentar el certificado adecuado para ese hostname. <a href=\"https:\/\/medium.com\/devkind\/tackling-421-misdirected-request-with-sni-header-in-nginx-60b7ec608913?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Medium+1<\/a><\/li>\n\n\n\n<li>Si NGINX act\u00faa como proxy hacia Apache sin reenviar correctamente ese SNI, o si Apache detecta que la conexi\u00f3n TLS no coincide con el virtual-host que el cliente quer\u00eda, entonces Apache puede responder con HTTP 421 indicando \u201cMisdirected Request: The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.\u201d <a href=\"https:\/\/forum.hestiacp.com\/t\/nginx-apache-ssl-421-misdirected-request\/19502?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Hestia Control Panel &#8211; Discourse+1<\/a><\/li>\n\n\n\n<li>En el foro de HestiaCP esto ha sido reportado luego de una actualizaci\u00f3n de Apache: \u201cAfter an apt update &amp; apt upgrade \u2026 websites now display an error 421: Misdirected Request \u2026\u201d <a href=\"https:\/\/forum.hestiacp.com\/t\/nginx-apache-ssl-421-misdirected-request\/19502?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Hestia Control Panel &#8211; Discourse+1<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2. Diagn\u00f3stico espec\u00edfico en HestiaCP<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Verifica en los registros de Apache del dominio afectado, se puede ver un log similar a:<br><code>AH02032: Hostname 10.0.0.120 (default host as no SNI was provided) and hostname example.com provided via HTTP have no compatible SSL setup<\/code> <a href=\"https:\/\/forum.hestiacp.com\/t\/nginx-apache-ssl-421-misdirected-request\/19502?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Hestia Control Panel &#8211; Discourse+1<\/a><\/li>\n\n\n\n<li>Esto indica que Apache recibi\u00f3 una conexi\u00f3n en la que el hostname indicado por el cliente (<code>example.com<\/code>) no coincide con el hostname que se negoci\u00f3 en TLS (o no se negoci\u00f3 SNI), y por tanto se considera \u201cmisdirected\u201d.<\/li>\n\n\n\n<li>En el entorno HestiaCP + NGINX + Apache, NGINX normalmente act\u00faa como frontend y pasa la conexi\u00f3n (proxy_pass) hacia Apache. Si NGINX no pasa el SNI correctamente al backend, el problema se manifiesta.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3. Soluci\u00f3n manual recomendada<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Uno de los trabajos m\u00e1s citados en los foros de HestiaCP es a\u00f1adir las directivas correctas en la configuraci\u00f3n de NGINX para habilitar el paso del SNI al backend Apache. Ejemplo de soluci\u00f3n:<\/p>\n\n\n<pre><code>for file in $(grep -l proxy_pass \/usr\/local\/hestia\/data\/templates\/web\/nginx\/*.stpl); do\n  if ! grep -q proxy_ssl_server_name &quot;$file&quot;; then\n    sed -i &#039;\/proxy_pass\/ i\\\n        proxy_ssl_server_name on;\\\n        proxy_ssl_name $host;&#039; &quot;$file&quot;\n  fi\ndone\n\n# Luego reconstruir todos los dominios de los usuarios\nfor i in $(v-list-users plain | cut -f1); do\n  echo &quot;Rebuilding web domains for user $i&quot;\n  v-rebuild-web-domains $i yes\ndone<\/code><\/pre>\n\n\n<h3 class=\"wp-block-heading\">4. Pasos concretos para HestiaCP<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Con\u00e9ctate por SSH al servidor.<\/li>\n\n\n\n<li>Crea un fichero de configuraci\u00f3n global de NGINX que incluya:<\/li>\n<\/ol>\n\n\n<pre><code>proxy_ssl_server_name on;\nproxy_ssl_name $host;\nproxy_ssl_session_reuse off;<\/code><\/pre>\n\n\n<p class=\"wp-block-paragraph\">Guarda este fichero, por ejemplo como <code>\/etc\/nginx\/conf.d\/fixssl.conf<\/code>. (La directiva <code>proxy_ssl_session_reuse off;<\/code> tambi\u00e9n aparece en soluciones para entornos similares. <a href=\"https:\/\/support.plesk.com\/hc\/en-us\/articles\/33500191748887-Websites-hosted-in-Plesk-are-not-accessible-after-a-recent-Apache-update-421-Misdirected-Request?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">support.plesk.com+1<\/a> )<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">3. Reinicia o recarga NGINX:<\/p>\n\n\n<pre><code>systemctl reload nginx<\/code><\/pre>\n\n\n<p class=\"wp-block-paragraph\">4. Si utilizas plantillas de Hestia para NGINX, edita los archivos <code>.stpl<\/code> en <code>\/usr\/local\/hestia\/data\/templates\/web\/nginx\/<\/code> a\u00f1adiendo las l\u00edneas anteriores antes de <code>proxy_pass<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">5. Reconstuye las configuraciones de los dominios usando el comando de Hestia:<\/p>\n\n\n<pre><code>v-rebuild-web-domains &lt;usuario&gt; yes<\/code><\/pre>\n\n\n<p class=\"wp-block-paragraph\">Rep\u00edtelo para todos los usuarios o usa un bucle automatizado como se mostr\u00f3 arriba.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">6. Una vez hecho, prueba acceder al dominio por HTTPS, limpia el cach\u00e9 del navegador o utiliza un modo \u201cinc\u00f3gnito\u201d para asegurar que no se est\u00e9 reutilizando una conexi\u00f3n anterior.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">7. Verifica los logs de Apache del dominio para confirmar que el error AH02032 no aparece m\u00e1s.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">8. Opcional: considera deshabilitar HTTP\/2 temporalmente para ese dominio si el problema persiste, ya que la reutilizaci\u00f3n de conexiones TLS en HTTP\/2 es parte de la causa de este error.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5. Consideraciones adicionales<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Este problema parece haberse disparado despu\u00e9s de una actualizaci\u00f3n de Apache (o de componentes relacionados) que cambi\u00f3 la forma en que Apache maneja SNI para conexiones proxied via NGINX. <a href=\"https:\/\/community.enhance.com\/d\/2947-421-misdirected-request-error-in-enhance-panel-after-recent-apache-update?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">community.enhance.com+1<\/a><\/li>\n\n\n\n<li>Aseg\u00farate de que todos tus virtual hosts (dominios) usan configuraci\u00f3n de SSL\/TLS homog\u00e9nea (mismos protocolos, par\u00e1metros de cifrado, etc.). Seg\u00fan la documentaci\u00f3n de Apache, la mezcla de configuraciones en hosts que comparten certificado o conexi\u00f3n puede provocar el 421. <a href=\"https:\/\/support.cpanel.net\/hc\/en-us\/articles\/1500004701722-421-Misdirected-Request?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">cPanel Support+1<\/a><\/li>\n\n\n\n<li>Verifica que no est\u00e9s utilizando un certificado compartido mal configurado (por ejemplo un certificado SAN que cubre m\u00faltiples dominios) sin que cada dominio tenga exactamente la misma configuraci\u00f3n TLS, lo cual es factor com\u00fan en este error. <a href=\"https:\/\/webidextrous.com\/how-to-solve-421-misdirected-request-errors\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Webidextrous LLC+1<\/a><\/li>\n\n\n\n<li>Tras aplicar la soluci\u00f3n, algunos usuarios en los foros reportaron que tuvieron problemas con correo electr\u00f3nico o servicios adicionales; aunque la comunidad aclara que los servicios de correo no deber\u00edan verse afectados directamente por este cambio de NGINX\/SSL. <a href=\"https:\/\/forum.hestiacp.com\/t\/after-421-misdirected-request-solution-problems-with-email\/19539?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noreferrer noopener\">Hestia Control Panel &#8211; Discourse<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6. Conclusi\u00f3n<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En resumen: si en tu servidor HestiaCP + NGINX + Apache aparece el error <strong>421 Misdirected Request<\/strong>, lo m\u00e1s probable es que sea un problema de SNI\/proxy entre NGINX y Apache. La soluci\u00f3n consiste en asegurar que NGINX pase correctamente el nombre de host al backend (Apache) mediante <code>proxy_ssl_server_name on;<\/code> y <code>proxy_ssl_name $host;<\/code>, as\u00ed como reconstruir los dominios para que las configuraciones se actualicen. Aplicar este remedio suele resolver el problema de inmediato.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Contenido:El error 421 Misdirected Request aparece cuando un cliente (por ejemplo un navegador) realiza una conexi\u00f3n HTTPS en la que el nombre de host solicitado no coincide con el nombre de host que el servidor presenta en la negociaci\u00f3n TLS (con SNI). En entornos donde NGINX act\u00faa como proxy frente a Apache (como en HestiaCP [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,14],"tags":[],"class_list":["post-616","post","type-post","status-publish","format-standard","hentry","category-administracion-de-servidores","category-paneles-de-control"],"_links":{"self":[{"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=\/wp\/v2\/posts\/616","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=616"}],"version-history":[{"count":0,"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=\/wp\/v2\/posts\/616\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=616"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=616"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.pirulug.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=616"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}