https://www.webnaranja.com/ Webnaranja en-us Mon, 22 Jun 2026 11:13:12 GMT 1440 Webnaranja Webnaranja Forums - Foro Webmasters Anónimos https://cyber.harvard.edu/rss/rss.html https://www.webnaranja.com/images/logo.gif https://www.webnaranja.com/ https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6527#6527 El fichero de estadísticas de access_ssl_log.webstat en access_ssl_log.webstat se esta llenando (mas de 50GB en el caso de un dominio mio). Este fichero es propio de cada dominio esta en el directorio logs de cada uno de ellos. Aunque lo borres mediante plesk o mediante comando desde el terminal linux, al día siguiente se vuelve a crear (con mas tamaño) porque el servidor lo tiene en memoria. Y eso aunque pares las estadísticas del dominio o desahibiltes las estadísticas web de todo el servidor. Varia<s soluciones de plesk no funcionan: https://support.plesk.com/hc/en-us/articles/12377343092631-How-to-remove-domain-logs-in-Plesk https://talk.plesk.com/threads/why-plesk-create-access_ssl_log-webstat-with-disabled-web-statistics.376620/ https://support.plesk.com/hc/en-us/articles/12377013328919-Plesk-webstat-log-files-are-growing-big Yo lo he solucionando parando primero los servicios de apache y nginx del servidor y luego eliminando desde plesk el fichero de estadisticas y por ultimo se arrancan los servicios apache y nginx. Así el fichero no esta en memoria cuando se elimina y el borrado se hace efectivo. Mon, 22 Jun 2026 11:13:12 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6521#6521 .videoWrapperContainer { max-width: 800px; margin: 20px auto; } .videoWrapper { position: relative; padding-bottom: 56.25%; /* 16:9 */ height: 0; overflow: hidden; } .videoWrapper iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } Video: /**/ Fitur 2026 Thu, 15 Jan 2026 01:13:15 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6518#6518 Problema: Un servidor Ubuntu 24.4 aislado que ha perdido su configuración de red. Todos los dominios albergados en el servidor, se han quedado sin servicio. Solo es accesible desde la consola del proveedor del hosting (Ionos). Al comando para conocer enrutamiento IP y rutas que tiene establecidas: netstat -rn Contesta con nada, ya que ha perdido las rutas. Diagnóstico del Error El mensaje principal parece ser: Cloud-init[2930]: Cannot apply stage final, no datasource found. Likely bad things to come! Cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: Esto significa que cloud-init, el programa responsable de la inicialización de la nube y la configuración de la máquina virtual (como establecer el hostname, añadir claves SSH, y ejecutar scripts de usuario) en el primer arranque, no pudo detectar el entorno donde se está ejecutando. Sin embargo el problema no es de clud-init, sino de red. Por eso no puede ejecutar los comandos. No ha cargado los enrutamientos de salida del servidor. ✨Ejecutar dhclient en la Consola El comando dhclient (DHCP client) intentará obtener o renovar una dirección IP y otra información de red (como la máscara de subred, puerta de enlace y DNS) de un servidor DHCP, que es lo que se conoce como "configurar la red de forma automática". Abre la Consola Remota o el Shell: Asegúrate de estar en la línea de comandos de tu servidor Ubuntu, donde ves el prompt (por ejemplo, usuario@servidor:~$). Ejecuta el Comando dhclient: Usa sudo para ejecutarlo con permisos de superusuario, ya que está modificando la configuración de red del sistema: Bash sudo dhclient ¿Qué hace esto? Por defecto, dhclient intentará buscar una interfaz de red que aún no esté configurada y solicitará una concesión (una dirección IP). Si solo tienes una interfaz, o si sabes cuál es (por ejemplo, eth0 o enp0s3), puedes especificarla para mayor precisión: sudo dhclient eth0 🥂 Mon, 17 Nov 2025 16:37:54 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6517#6517 Las fechas del Madrid Tech Show 2026 serán del 4 al 5 de noviembre, como indica el cartel. Fri, 31 Oct 2025 15:21:56 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6514#6514 Hoy hemos tenido una caída mundial de los servicios de Amazon Web Services (AWS) que alberga muchos millones de webs y que soporta servicios de terceros tan críticos como transacciones de pago online, tarjetas de crédito, bancos, hospitales... Se han visto afectados desde las 8:40 (hora española) servicios en la nube y webs o servicios tan famosos como: Amazon, Alexa, PrimeVideo, Duolingo, Fortnite, McDonalds, Perplexity o Canva. La compañía todavía no ha explicado completamente la causa de la caída. Amazon ha indicado que la posible raíz del problema, puede estar relacionada con la resolución de DNS en la API de DynamoDB (bases de datos) en la región US-EAST-1. Los servicios comenzaron a recuperarse sobre las 11:30 hora española. Mon, 20 Oct 2025 13:41:21 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6511#6511 De pronto aparecen miles de usuarios chinos en tu web, pese a que tu contenido está en español. ¿La estas petando en China? Va a ser que no. Comprueba el "Tiempo de interacción medio por usuario activo" en Google Analytics. Si se aproxima a cero segundos, es que son bots, no usuarios normales. Algunos bots, spiders o crawlers chinos viene barriendo webs desde este verano. No solo no se anuncian como bots, sino que además se descargan todos los ficheros e incluso ejecutan JavaScript como el de Analytics y falsean todas las estadísticas. Al no anunciarse como bots no podemos aplicar el bloqueo de bots del HTTP_USER_AGENT: https://www.webnaranja.com/foros.php?p=6510&q=Lista-spam-bloquear-htaccess#6510 Yo como los bloqueo, pues como he detectado que tiene el navegador en chino, lo hago en el fichero .htaccess que tengo en el raiz (/) de mi dominio. Lo puedo hacer de dos formas. La primera redirigiendo al raiz con 301 y me olvido de el (solo rastrea el home): Quote:: <IfModule mod_rewrite.c> RewriteEngine On # Si acepta chino pero no español → redirigir al raíz RewriteCond %{HTTP:Accept-Language} ^.*zh [NC] RewriteCond %{HTTP:Accept-Language} !es [NC] RewriteRule ^.*$ / [R=301,L,QSD] O directamente bloqueándolo con 403 (no autorizado): Quote:: # Condición 1: contiene chino, pero NO contiene español RewriteCond %{HTTP:Accept-Language} zh [NC] RewriteCond %{HTTP:Accept-Language} !es [NC] # Si se cumplen ambas → bloquear RewriteRule .* - [F,L] Recordad que hay que añadir las líneas siempre después de la línea: RewriteEngine On Sun, 21 Sep 2025 18:26:24 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6510#6510 Voy a poner una lista detallada de bots que tengo bloqueados en el fichero .htaccess de mi servidor Apache y que está situado en el raiz del dominio. La lista de spider, crawlers o rastreadores molestos están actualizados a septiembre de 2025. Para detectar si es o no un Bot, uso el "HTTP_USER_AGENT" Agente de Usuario de su navegador. Iré actualizando la lista con el tiempo: Quote:: <IfModule mod_rewrite.c> RewriteEngine On # bloqueo de spiders RewriteCond %{HTTP_USER_AGENT} ^.*(amazonbot|Bytedance|Bytespider|PetalBot|UptimeRobot|seocompany|LieBaoFast|SEOkicks|Uptimebot|Cliqzbot|ssearch_bot|domaincrawler|spot|DigExt|Sogou|MegaIndex|majestic|80legs|SISTRIX|HTTrack|Semrush|MJ12|Ezooms|CCBot|TalkTalk|Ahrefs|BLEXBot).*$ [NC] RewriteRule .* - [F,L] RewriteCond %{HTTP_USER_AGENT} ^.*(Imagesift|SeekportBot|seekport|dataforseo|turnitin|Barkrowler|DotBot|Mediatoolkitbot|iboubot|Aliyun).*$ [NC] RewriteRule .* - [F,L] RewriteCond %{HTTP_USER_AGENT} (?:ahrefsBot|Meta-ExternalAgent) [NC] RewriteRule ^ - [F,L] Estos bots a mi no aportan ningún tráfico y sustraen numerosos recursos así que, yo personalmente los corto en seco. Pero es posible que a alguna web le sean útiles, así que debéis pensarlo (por ejemplo amazonbot). Si no tenéis ni idea, mejor meterlo tal cual. Es importante que tengáis el modulo rewrite a on, como pone al comienzo de mi código. RewriteEngine On Este bloqueo no funciona con los bots chinos que no se anuncian e intentan sustraer tus contenidos de forma disimulada. Pero para eso tenemos otro post: Como bloquear usuarios chinos en tu web Thu, 18 Sep 2025 23:45:52 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6508#6508 Reinicio del sistema de red con el comando: systemctl restart networking Root@server:~# nslookup gmail.com ;; communications error to 212.227.123.16#53: timed out ;; communications error to 212.227.123.16#53: timed out No comunica con los DNS, así que reiniciamos las conexiones de red Root@server:~# sudo systemctl restart networking Root@server:~# nslookup gmail.com Server: 2001:8d8:fe:53:72ec::1 Address: 2001:8d8:fe:53:72ec::1#53 Non-authoritative answer: Name: gmail.com Address: 142.250.185.5 Name: gmail.com Address: 2a00:1450:4003:80a::2005 Root@server:~# Ya funciona. Sun, 20 Jul 2025 12:20:49 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6507#6507 Comando para instalar clave de plesk desde consola de Linux, como root, donde el número de licencia es: "A00300-bbb-xxxxx-aaaaa-xxxxx": Root@xxxxserver:~# plesk bin license -i A00300-bbb-xxxxx-aaaaa-xxxxx [2025-07-19 02:18:55.545] 6579:687ae430552ce ERR [panel] KA Request Failure code: 2 Network failure [2025-07-19 02:18:55.545] 6579:687ae430552ce ERR [panel] KA Request Failure desc: cURL cannot communicate with license server https://id-00.kaid.plesk.com:443/ (): Timeout was reached(28) CURL cannot communicate with license server https://id-00.kaid.plesk.com:443/ (): Couldn't resolve host name(6) [2025-07-19 02:18:55.545] 6579:687ae430552ce ERR [panel] KA Request Failure additional information: cURL verbose output: * Host id-00.kaid.plesk.com:443 was resolved. * IPv6: (none) * IPv4: 91.204.25.7, 91.204.25.5, 195.214.233.81, 195.214.233.82, 195.214.233.80, 91.204.25.6 * Trying 91.204.25.7:443... * ipv4 connect timeout after 29993ms, move on! * Trying 91.204.25.5:443... * ipv4 connect timeout after 14995ms, move on! * Trying 195.214.233.81:443... * ipv4 connect timeout after 7497ms, move on! * Trying 195.214.233.82:443... * ipv4 connect timeout after 3748ms, move on! * Trying 195.214.233.80:443... * ipv4 connect timeout after 1873ms, move on! * Trying 91.204.25.6:443... * ipv4 connect timeout after 1871ms, move on! * Failed to connect to id-00.kaid.plesk.com port 443 after 60002 ms: Timeout was reached * Closing connection CURL verbose output: * Could not resolve host: id-00.kaid.plesk.com * Closing connection Could not update the license. Make sure that connections to the license server ka.plesk.com on TCP port 443 are not blocked. To fix the issue, follow the instructions described in KB https://support.plesk.com/hc/en-us/articles/12388137260695. Exit status 1 Comprobamos que el servidor resuelve la dirección bien: Root@xxxxserver:~# nslookup id-00.kaid.plesk.com Server: 2001:8d8:fe:53:72ec::1 Address: 2001:8d8:fe:53:72ec::1#53 Non-authoritative answer: Id-00.kaid.plesk.com canonical name = ka.plesk.com. Name: ka.plesk.com Address: 195.214.233.82 Name: ka.plesk.com Address: 195.214.233.81 Name: ka.plesk.com Address: 91.204.25.6 Name: ka.plesk.com Address: 195.214.233.80 Name: ka.plesk.com Address: 91.204.25.7 Name: ka.plesk.com Address: 91.204.25.5 Root@xxxxserver:~# El número de licencia lo podéis obtener de la página de administración del servidor dedicado de vuestro proveedor. Comprobamos que el puerto 443 esta abierto y vemos que hay conexiones establecidas, por tanto el fallo debe ser otro: Root@xxxxserver:~# netstat -natu | grep 443 Tcp 0 0 82.223.11.99:443 0.0.0.0:* LISTEN Tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN Tcp 0 0 10.5.173.236:443 0.0.0.0:* LISTEN Tcp 0 0 82.223.11.99:443 213.180.203.193:57194 ESTABLISHED Tcp 0 0 82.223.11.99:443 38.122.40.91:44324 TIME_WAIT Tcp 0 0 82.223.11.99:443 17.241.227.66:54916 ESTABLISHED Tcp 0 0 82.223.11.99:443 5.255.231.177:36310 ESTABLISHED Tcp 0 0 82.223.11.99:443 79.95.87.193:32967 TIME_WAIT Tcp 0 0 82.223.11.99:443 17.241.75.201:35344 ESTABLISHED Tcp 0 0 82.223.11.99:443 185.147.102.118:16804 ESTABLISHED Tcp 0 0 82.223.11.99:443 77.88.47.10:33466 ESTABLISHED Tcp 0 0 82.223.11.99:443 95.108.213.89:64136 ESTABLISHED Tcp 0 0 82.223.11.99:443 54.92.171.106:47810 TIME_WAIT Tcp 0 0 82.223.11.99:443 79.117.246.94:57304 ESTABLISHED Tcp 0 0 82.223.11.99:443 87.250.224.76:63680 ESTABLISHED Tcp 0 0 82.223.11.99:443 5.255.231.249:34650 ESTABLISHED Tcp 0 0 82.223.11.99:443 17.241.75.87:58064 ESTABLISHED Tcp 0 0 82.223.11.99:443 38.52.155.226:38522 TIME_WAIT Tcp 0 0 82.223.11.99:443 212.12.124.52:46238 TIME_WAIT Tcp 0 0 82.223.11.99:443 176.88.175.242:53724 TIME_WAIT Tcp 0 0 82.223.11.99:443 168.197.107.91:21882 ESTABLISHED Tcp 0 0 82.223.11.99:443 197.93.98.217:56980 ESTABLISHED Tcp 0 0 82.223.11.99:443 45.6.183.98:36053 TIME_WAIT Tcp 0 0 82.223.11.99:443 5.255.231.164:48408 ESTABLISHED Tcp 0 0 82.223.11.99:443 41.226.234.167:42660 TIME_WAIT Tcp 0 0 82.223.11.99:443 177.86.37.113:43880 TIME_WAIT Sat, 19 Jul 2025 00:30:05 GMT https://www.webnaranja.com/index.php?name=Forums&file=viewtopic&p=6506#6506 Al final, el problema de la falta de conexión se solucionó con un reinicio de servidor. Ionos nos dejo tirados con el problema, pese a que les presionamos ya que consideramos que si una actualización de Plesk viene mal (en este caso a dos servidores) es también responsabilidad de ellos. Pero no sirvió de nada. No aceptan ni responsabilidad sobre su producto (servidor dedicado + plesk), ni dar soporte. Sat, 19 Jul 2025 00:25:22 GMT