cutonboy
Delta
Verificación en dos pasos activada
Verificado por Binance
Se puede haer en plesk?
Tutorial: Reverse Proxy con HestiaCP y Nginx: oculta la IP de origen (guía visual)
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
Pero no tendria sentido pagar una licencia solo para eso🤣
yuck
Beta
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
wmasterSolutions
VIP
Mi
Verificación en dos pasos activada
¡Usuario popular!
Suscripción a IA
@Carlos Frias es uno de mis héroes favoritos en Forobeta
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
¡Tutorial reactivado y actualizado! 😎
Volví a leer el hilo completo y tenía pendientes tanto las dudas como agradecerles a quienes se pasaron a comentar. Lo junto todo aquí para no llenar el tema de respuestas seguidas.
La guía del primer mensaje ya está renovada: repositorio y plantillas reparados, barrido automático con respaldo, nuevas capturas y HTTPS verificado hasta el servidor final. Rehice el ejercicio desde cero y dejé explicado qué se probó y qué queda fuera del alcance. El proceso conserva la sencillez de la receta original.
Voy primero con las consultas que habían quedado en el hilo:
Tenías razón, ese repositorio lo retiré yo y dejé los enlaces rotos. Te debía esta reparación. Ya están los archivos en el nuevo repositorio público y el primer mensaje tiene el procedimiento actualizado. El paquete del proxy ahora lo crea el script con la CLI de Hestia; ya no dependes de descargar aquel default.pkg por separado. Gracias por avisarlo.
Volví a leer todo lo que fuiste contando, y gracias también por compartir cómo lo ibas resolviendo. Aquella limitación de Ubuntu no conviene arrastrarla como una regla permanente: rehice el ejercicio con Ubuntu 24.04 LTS y el instalador estable de Hestia. Para montarlo hoy, revisa la compatibilidad oficial y utiliza un VPS limpio. Para cambiar el sistema se usa Rebuild/Reinstall en el panel del VPS del proveedor, no dentro de Hestia. Antes respalda cualquier dato y guarda las nuevas credenciales: la reinstalación reemplaza el sistema.
Aquí actualizo también mi recomendación antigua: el objetivo ahora es Full (strict), con el certificado del VPS funcionando. Que aparezca el candado del navegador no demuestra que estén cifrados los demás tramos; Flexible conecta Cloudflare con el VPS por HTTP. Las plantillas nuevas, además, conectan el VPS con el servidor final mediante HTTPS y verifican su certificado.
El 521 significa que el servidor al que apunta Cloudflare rechaza la conexión. Para el caso dominio/www: apunta ambos al VPS proxy, corrige los AAAA que apunten a otro servidor, agrega www como alias en Hestia y confirma que Nginx escuche en 443 para Full (strict), aceptando las conexiones de Cloudflare. Comprueba por HTTPS tanto el dominio como www.
Para el 403 de Let’s Encrypt: lee el registro de emisión, verifica que cada nombre solicitado resuelva al VPS y permite el challenge HTTP en el puerto 80. Para la primera emisión puedes dejar esos registros en Solo DNS. Si el bloqueo es una regla, limita la excepción al challenge necesario; un user-agent por sí solo no identifica de forma fiable a Let’s Encrypt. Emite el certificado antes de forzar HTTPS y mantén funcionando la renovación de ambos extremos.
Este detalle sí lo incorporé a la reparación. La plantilla rp nueva envía al origen también robots.txt y los sitemaps, incluido sitemap_index.xml si tu WordPress lo publica. Probé robots.txt y un sitemap comparando el contenido recibido con el del origen. En tu instalación comprueba que esté seleccionada rp y revisa la caché externa; borrar un archivo local no corrige por sí solo qué ubicación de Nginx atiende la petición.
Sobre cómo podrían descubrir el origen: el historial DNS, IPv6, correo o una petición saliente de la aplicación pueden revelar su IP. Conocer esa IP no concede acceso al servidor. Interceptar tráfico requiere una posición desde la que observarlo o intervenirlo; TLS protege su contenido, aunque no oculta las direcciones a los operadores de red. La defensa combina HTTPS verificado, aplicación actualizada y restricción del acceso web al origen cuando el proveedor lo permita. El proxy añade esa separación, no anonimato absoluto.
Buen apunte; esta parte merecía quedar mejor resuelta. La actualización ya utiliza HTTPS entre el VPS y el origen, con SNI y verificación del certificado, sin desactivar la validación para que “funcione”.
El origen puede usar 443 con TLS válido. La restricción de acceso es otra parte del trabajo: si administras ambos extremos, puedes limitar quién llega al origen o emplear una red privada/VPN. En hosting compartido toca coordinarlo con el proveedor. Para la variante VPN, conecta ambos servidores por el túnel, dirige el proxy a la IP privada del origen y permite su acceso web solo desde la red o interfaz autorizada, conservando administración y renovación SSL. Si mantienes HTTPS dentro del túnel, el nombre SNI debe seguir coincidiendo con el certificado del origen. Eso requiere control de ambos extremos; un hosting compartido normalmente no te permite crear esa VPN. Esta edición comprueba el recorrido HTTPS público, no implementa esa variante. Gracias por abrir esa conversación.
Ya tienes una actualización que recoge la parte del cifrado que comentabais: HTTPS hasta el origen, validación del certificado y explicación de los límites de privacidad. La alternativa que pedías queda así: VPN entre los dos servidores, Nginx apuntando a la IP del túnel del origen y acceso web restringido a ese enlace, sin perder la administración ni la renovación de certificados. Necesitas administrar ambos servidores. Si el origen es compartido, el recorrido disponible en esta guía es HTTPS verificado y las restricciones que permita su proveedor. La VPN requiere ese montaje adicional y no forma parte de las pruebas publicadas.
Sí, en Plesk para Linux también se puede adaptar un Reverse Proxy con Nginx. Y matizo aquella respuesta tan corta que te di 😅: si ya tienes Plesk, tiene sentido aprovecharlo. Lo que no se traslada directamente son rp.tpl/rp.stpl ni el script de Hestia; hay que adaptar la configuración a los mecanismos de Plesk y conservarla frente a reconstrucciones. Su documentación explica las directivas adicionales de Nginx. El ejercicio que acabo de comprobar sigue siendo el de Hestia.
Sí, si tu actualizador descarga los ejecutables por HTTP/HTTPS, puedes poner esas descargas detrás del proxy. Para archivos grandes probaría también integridad, reanudación de descargas mediante Range y tiempos de espera; que cargue la portada no valida todo ese recorrido. Los servicios de Windows que usen otros protocolos necesitan otra configuración. Gracias por aportar ese uso, que va más allá de servir una página.
Gracias por haberle acercado las instrucciones del proveedor cuando se atascó con la reinstalación. Esa ayuda vino bien en el momento. En la revisión dejé el recorrido independiente de un panel de VPS concreto: sistema compatible, instalación limpia y accesos del proveedor que utilice cada uno. Así la guía no queda atada a que un botón siga llamándose igual.
Gracias, esa es la idea: que el dominio publique la IP del proxy mientras la web permanece en el origen. Ahora expliqué mejor también lo que puede revelar ese origen, para que nadie confunda esa capa de privacidad con anonimato absoluto.
Y gracias también a todos los que dejaron su apoyo:
¡Gracias a ti por estrenarlo con ese ánimo! Lo dejé de nuevo al día para que siga siendo útil.
¡Gracias por pasarte! Ahí queda la revisión por si vuelves a necesitar el montaje.
Un gusto compartirlo, Daniel. Gracias por el apoyo desde la primera versión.
Jajaja, gracias, tigre 😎. Tocaba darle mantenimiento al tutorial también, que esos enlaces no podían quedarse así.
¡Gracias! Ha pasado un tiempito desde aquel mensaje 😅. Por si vuelves a usarlo, ya tienes las plantillas reparadas y las capturas renovadas.
Gracias, man. Se aprecia que te tomaras el rato de dejar el comentario.
¡Gracias por esas palabras! Esta vez repasé también los detalles que habían quedado pendientes en los comentarios.
Gracias a ti por recibirlo así. Compartirlo tiene más sentido cuando entre todos van saliendo mejoras.
¡Gracias, compa! 😎 Ya quedó reparado para poder seguir aprovechándolo.
Esa es buena razón para probarlo 😄. Haz el laboratorio en un VPS nuevo y con un dominio de prueba; el barrido no es para un panel que ya aloje webs.
¡Gracias por guardarlo! Ya merece otra visita a esos favoritos, que cambió bastante desde entonces.
Gracias a ti, Antik. Ojalá la revisión te sirva para entender mejor qué ocurre en cada tramo del proxy.
Jajaja, el «Es bellísimo» tenía que quedarse 😂. Lo mantuve en la guía renovada.
Eso era lo que buscaba al publicarlo. Gracias por contarlo y por guardarlo para después 💪.
Gracias por el apoyo, Gregh. Ya quedó disponible otra vez con los archivos corregidos.
¡Gracias! Si lo retomas, empieza por la versión nueva del primer mensaje; así usas las plantillas que acabo de comprobar.
Gracias a ti por el comentario. Da gusto volver al hilo y ver que tanta gente se animó a aprender con él.
Jajaja, gracias por el cariño. Con mantener vivos los enlaces ya voy cumpliendo una misión pendiente 😅.
De nada, compa. Intenté conservar esa sencillez y aclarar las partes donde surgieron dudas.
Jajaja, ¡gracias, Mega! Ahí queda la puesta al día 😎.
Muchas gracias por ese mensaje. Me gusta que el foro conserve tutoriales que se puedan seguir y discutir entre todos; por eso quise reparar este y responder lo que había quedado abierto.
Gracias a ti por pasarte. Me alegra que la explicación te resultara útil.
¡Gracias! Ahora también dejé explicadas las comprobaciones y los límites del montaje.
Jajaja, me alegra que te sirviera otra vez. Ya tocaba devolverle el favor al hilo y dejarlo funcionando de nuevo.
Jajaja, gracias por el cariño y por levantar el hilo. Ya puedo volver con el repositorio reparado y la actualización publicada, que era lo que faltaba 😄.
Gracias a todos por darle vida al hilo. Los archivos reparados, las capturas nuevas y el procedimiento completo ya están en el primer mensaje. Ahí queda la puesta al día de Octubre de 2026 🙂.
Volví a leer el hilo completo y tenía pendientes tanto las dudas como agradecerles a quienes se pasaron a comentar. Lo junto todo aquí para no llenar el tema de respuestas seguidas.
La guía del primer mensaje ya está renovada: repositorio y plantillas reparados, barrido automático con respaldo, nuevas capturas y HTTPS verificado hasta el servidor final. Rehice el ejercicio desde cero y dejé explicado qué se probó y qué queda fuera del alcance. El proceso conserva la sencillez de la receta original.
Voy primero con las consultas que habían quedado en el hilo:
Tenías razón, ese repositorio lo retiré yo y dejé los enlaces rotos. Te debía esta reparación. Ya están los archivos en el nuevo repositorio público y el primer mensaje tiene el procedimiento actualizado. El paquete del proxy ahora lo crea el script con la CLI de Hestia; ya no dependes de descargar aquel default.pkg por separado. Gracias por avisarlo.
Volví a leer todo lo que fuiste contando, y gracias también por compartir cómo lo ibas resolviendo. Aquella limitación de Ubuntu no conviene arrastrarla como una regla permanente: rehice el ejercicio con Ubuntu 24.04 LTS y el instalador estable de Hestia. Para montarlo hoy, revisa la compatibilidad oficial y utiliza un VPS limpio. Para cambiar el sistema se usa Rebuild/Reinstall en el panel del VPS del proveedor, no dentro de Hestia. Antes respalda cualquier dato y guarda las nuevas credenciales: la reinstalación reemplaza el sistema.
Aquí actualizo también mi recomendación antigua: el objetivo ahora es Full (strict), con el certificado del VPS funcionando. Que aparezca el candado del navegador no demuestra que estén cifrados los demás tramos; Flexible conecta Cloudflare con el VPS por HTTP. Las plantillas nuevas, además, conectan el VPS con el servidor final mediante HTTPS y verifican su certificado.
El 521 significa que el servidor al que apunta Cloudflare rechaza la conexión. Para el caso dominio/www: apunta ambos al VPS proxy, corrige los AAAA que apunten a otro servidor, agrega www como alias en Hestia y confirma que Nginx escuche en 443 para Full (strict), aceptando las conexiones de Cloudflare. Comprueba por HTTPS tanto el dominio como www.
Para el 403 de Let’s Encrypt: lee el registro de emisión, verifica que cada nombre solicitado resuelva al VPS y permite el challenge HTTP en el puerto 80. Para la primera emisión puedes dejar esos registros en Solo DNS. Si el bloqueo es una regla, limita la excepción al challenge necesario; un user-agent por sí solo no identifica de forma fiable a Let’s Encrypt. Emite el certificado antes de forzar HTTPS y mantén funcionando la renovación de ambos extremos.
Este detalle sí lo incorporé a la reparación. La plantilla rp nueva envía al origen también robots.txt y los sitemaps, incluido sitemap_index.xml si tu WordPress lo publica. Probé robots.txt y un sitemap comparando el contenido recibido con el del origen. En tu instalación comprueba que esté seleccionada rp y revisa la caché externa; borrar un archivo local no corrige por sí solo qué ubicación de Nginx atiende la petición.
Sobre cómo podrían descubrir el origen: el historial DNS, IPv6, correo o una petición saliente de la aplicación pueden revelar su IP. Conocer esa IP no concede acceso al servidor. Interceptar tráfico requiere una posición desde la que observarlo o intervenirlo; TLS protege su contenido, aunque no oculta las direcciones a los operadores de red. La defensa combina HTTPS verificado, aplicación actualizada y restricción del acceso web al origen cuando el proveedor lo permita. El proxy añade esa separación, no anonimato absoluto.
Buen apunte; esta parte merecía quedar mejor resuelta. La actualización ya utiliza HTTPS entre el VPS y el origen, con SNI y verificación del certificado, sin desactivar la validación para que “funcione”.
El origen puede usar 443 con TLS válido. La restricción de acceso es otra parte del trabajo: si administras ambos extremos, puedes limitar quién llega al origen o emplear una red privada/VPN. En hosting compartido toca coordinarlo con el proveedor. Para la variante VPN, conecta ambos servidores por el túnel, dirige el proxy a la IP privada del origen y permite su acceso web solo desde la red o interfaz autorizada, conservando administración y renovación SSL. Si mantienes HTTPS dentro del túnel, el nombre SNI debe seguir coincidiendo con el certificado del origen. Eso requiere control de ambos extremos; un hosting compartido normalmente no te permite crear esa VPN. Esta edición comprueba el recorrido HTTPS público, no implementa esa variante. Gracias por abrir esa conversación.
Ya tienes una actualización que recoge la parte del cifrado que comentabais: HTTPS hasta el origen, validación del certificado y explicación de los límites de privacidad. La alternativa que pedías queda así: VPN entre los dos servidores, Nginx apuntando a la IP del túnel del origen y acceso web restringido a ese enlace, sin perder la administración ni la renovación de certificados. Necesitas administrar ambos servidores. Si el origen es compartido, el recorrido disponible en esta guía es HTTPS verificado y las restricciones que permita su proveedor. La VPN requiere ese montaje adicional y no forma parte de las pruebas publicadas.
Sí, en Plesk para Linux también se puede adaptar un Reverse Proxy con Nginx. Y matizo aquella respuesta tan corta que te di 😅: si ya tienes Plesk, tiene sentido aprovecharlo. Lo que no se traslada directamente son rp.tpl/rp.stpl ni el script de Hestia; hay que adaptar la configuración a los mecanismos de Plesk y conservarla frente a reconstrucciones. Su documentación explica las directivas adicionales de Nginx. El ejercicio que acabo de comprobar sigue siendo el de Hestia.
Sí, si tu actualizador descarga los ejecutables por HTTP/HTTPS, puedes poner esas descargas detrás del proxy. Para archivos grandes probaría también integridad, reanudación de descargas mediante Range y tiempos de espera; que cargue la portada no valida todo ese recorrido. Los servicios de Windows que usen otros protocolos necesitan otra configuración. Gracias por aportar ese uso, que va más allá de servir una página.
Gracias por haberle acercado las instrucciones del proveedor cuando se atascó con la reinstalación. Esa ayuda vino bien en el momento. En la revisión dejé el recorrido independiente de un panel de VPS concreto: sistema compatible, instalación limpia y accesos del proveedor que utilice cada uno. Así la guía no queda atada a que un botón siga llamándose igual.
Gracias, esa es la idea: que el dominio publique la IP del proxy mientras la web permanece en el origen. Ahora expliqué mejor también lo que puede revelar ese origen, para que nadie confunda esa capa de privacidad con anonimato absoluto.
Y gracias también a todos los que dejaron su apoyo:
¡Gracias a ti por estrenarlo con ese ánimo! Lo dejé de nuevo al día para que siga siendo útil.
¡Gracias por pasarte! Ahí queda la revisión por si vuelves a necesitar el montaje.
Un gusto compartirlo, Daniel. Gracias por el apoyo desde la primera versión.
Jajaja, gracias, tigre 😎. Tocaba darle mantenimiento al tutorial también, que esos enlaces no podían quedarse así.
¡Gracias! Ha pasado un tiempito desde aquel mensaje 😅. Por si vuelves a usarlo, ya tienes las plantillas reparadas y las capturas renovadas.
Gracias, man. Se aprecia que te tomaras el rato de dejar el comentario.
¡Gracias por esas palabras! Esta vez repasé también los detalles que habían quedado pendientes en los comentarios.
Gracias a ti por recibirlo así. Compartirlo tiene más sentido cuando entre todos van saliendo mejoras.
¡Gracias, compa! 😎 Ya quedó reparado para poder seguir aprovechándolo.
Esa es buena razón para probarlo 😄. Haz el laboratorio en un VPS nuevo y con un dominio de prueba; el barrido no es para un panel que ya aloje webs.
¡Gracias por guardarlo! Ya merece otra visita a esos favoritos, que cambió bastante desde entonces.
Gracias a ti, Antik. Ojalá la revisión te sirva para entender mejor qué ocurre en cada tramo del proxy.
Jajaja, el «Es bellísimo» tenía que quedarse 😂. Lo mantuve en la guía renovada.
Eso era lo que buscaba al publicarlo. Gracias por contarlo y por guardarlo para después 💪.
Gracias por el apoyo, Gregh. Ya quedó disponible otra vez con los archivos corregidos.
¡Gracias! Si lo retomas, empieza por la versión nueva del primer mensaje; así usas las plantillas que acabo de comprobar.
Gracias a ti por el comentario. Da gusto volver al hilo y ver que tanta gente se animó a aprender con él.
Jajaja, gracias por el cariño. Con mantener vivos los enlaces ya voy cumpliendo una misión pendiente 😅.
De nada, compa. Intenté conservar esa sencillez y aclarar las partes donde surgieron dudas.
Jajaja, ¡gracias, Mega! Ahí queda la puesta al día 😎.
Muchas gracias por ese mensaje. Me gusta que el foro conserve tutoriales que se puedan seguir y discutir entre todos; por eso quise reparar este y responder lo que había quedado abierto.
Gracias a ti por pasarte. Me alegra que la explicación te resultara útil.
¡Gracias! Ahora también dejé explicadas las comprobaciones y los límites del montaje.
Jajaja, me alegra que te sirviera otra vez. Ya tocaba devolverle el favor al hilo y dejarlo funcionando de nuevo.
Jajaja, gracias por el cariño y por levantar el hilo. Ya puedo volver con el repositorio reparado y la actualización publicada, que era lo que faltaba 😄.
Gracias a todos por darle vida al hilo. Los archivos reparados, las capturas nuevas y el procedimiento completo ya están en el primer mensaje. Ahí queda la puesta al día de Octubre de 2026 🙂.
Daniel Muñoz
1
Pi
Programador
Verificado
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
Excelente, mi pregunta es, no es más fácil con wireguard ?
O incluso un túnel de cloudflare?
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
No son métodos "Offshore" si logras algo así es probable que en el camino corto termines con la cuenta o la zona suspendida.
El cliente que usa esta forma de protegerse se está protegiendo contra las denuncias de DMCA o inclusive de preocupaciones regulatorias más allá de lo normal.
Es decir, cuando el cliente no quiere que ni siquiera Cloudflare sepa dónde está alojado el Website, por eso se trata de divorciar una cosa de la otra.
Temas similares
