Cuando contratamos un hosting, instalamos WordPress o empezamos a aprender desarrollo web aparece constantemente una palabra:

servidor.

“El servidor está caído.”

“El servidor tarda en responder.”

“Necesitas reiniciar el servidor.”

“El problema está en el servidor.”

“Ese hosting utiliza servidores en Europa.”

Pero ¿qué es realmente un servidor y qué ocurre desde que escribimos una dirección en el navegador hasta que aparece una página web?

Voy a intentar explicarlo desde cero y sin asumir demasiados conocimientos técnicos.

¿Qué es un servidor?

Un servidor es, simplificando bastante, un sistema que proporciona recursos o servicios a otros equipos o aplicaciones.

En Internet podemos tener servidores destinados a diferentes funciones:

• Servidores web.

• Servidores de bases de datos.

• Servidores DNS.

• Servidores de correo.

• Servidores de archivos.

• Servidores de aplicaciones.

Cuando hablamos de páginas web, normalmente nos interesa especialmente el servidor web.

¿Qué es un servidor web?

El término puede utilizarse para hablar tanto de la máquina que aloja determinados servicios como del software encargado de recibir y responder peticiones web.

Esto puede generar cierta confusión al empezar.

Podemos tener una máquina donde se ejecuta software como:

Nginx

o:

Apache

Ese software recibe solicitudes HTTP/HTTPS y devuelve las respuestas correspondientes.

Por eso cuando alguien dice:

Tengo un problema con el servidor web.

puede estar hablando del software, de la máquina o incluso de la infraestructura en general.

Hay que mirar el contexto.

¿Qué ocurre cuando visitas una página?

Imaginemos que escribimos una dirección en nuestro navegador.

De forma muy simplificada ocurre algo parecido a:

1. El navegador necesita localizar el servidor.

2. DNS ayuda a determinar hacia dónde debe dirigirse.

3. El navegador establece una conexión.

4. Envía una petición HTTP o HTTPS.

5. El servidor recibe la solicitud.

6. La aplicación procesa lo necesario.

7. Se genera una respuesta.

8. El navegador recibe los datos.

9. Interpreta HTML, CSS, JavaScript, imágenes y otros recursos.

Todo esto puede ocurrir en una fracción de segundo.

El servidor no es el dominio

Esta diferencia es importante.

Tenemos tres conceptos relacionados, pero diferentes:

Dominio

Es el nombre que utilizamos para acceder al proyecto.

Por ejemplo:

ejemplo.com

DNS

Ayuda a determinar a qué infraestructura debe dirigirse ese dominio.

Servidor

Es donde se ejecutan o alojan los servicios necesarios para responder.

Podemos cambiar de servidor manteniendo exactamente el mismo dominio.

Un dominio puede apuntar a otro servidor

Supongamos que nuestra web está alojada en un proveedor.

Más adelante decidimos migrarla.

Podemos mover:

• Archivos.

• Base de datos.

• Configuración.

al servidor nuevo.

Después modificamos la configuración correspondiente para que el dominio termine resolviendo hacia la nueva infraestructura.

Para el usuario, la dirección continúa siendo:

ejemplo.com

aunque por detrás hayamos cambiado completamente de proveedor.

Servidor y hosting tampoco significan exactamente lo mismo

Cuando contratamos hosting estamos comprando un servicio de alojamiento.

El proveedor utiliza servidores para ofrecer ese servicio.

En un hosting compartido, diferentes clientes pueden utilizar recursos de una misma infraestructura.

En otros modelos podemos disponer de entornos con características diferentes.

Por eso decir:

Tengo un hosting.

y:

Tengo un servidor dedicado.

no describe necesariamente la misma situación.

¿Qué es un hosting compartido?

En un alojamiento compartido diferentes webs utilizan recursos dentro de una infraestructura común gestionada por el proveedor.

Tiene una ventaja enorme:

simplicidad.

Normalmente no necesitamos administrar desde cero:

• Sistema operativo.

• Servidor web.

• Actualizaciones del sistema.

• Configuración completa de red.

• Determinados servicios.

• Parte de la seguridad de infraestructura.

El proveedor se encarga de buena parte de ese trabajo.

Para muchas páginas pequeñas y medianas puede ser más que suficiente.

Compartido no significa necesariamente malo

Existe cierta obsesión con pensar:

Hosting compartido = amateur.

No es así.

Un buen alojamiento compartido puede funcionar perfectamente para multitud de webs.

Lo importante es analizar:

• Recursos.

• Rendimiento.

• Soporte.

• Limitaciones.

• Seguridad.

• Necesidades del proyecto.

Una web pequeña no necesita automáticamente un servidor gigantesco.

¿Qué es un VPS?

VPS significa Virtual Private Server.

Mediante virtualización podemos disponer de un entorno virtual con recursos y configuración propios dentro de una infraestructura física.

Un VPS suele proporcionar bastante más control que un hosting compartido tradicional.

Podemos, dependiendo del servicio:

• Instalar software.

• Configurar servicios.

• Administrar usuarios.

• Modificar el servidor web.

• Gestionar firewall.

• Configurar bases de datos.

• Automatizar despliegues.

Pero ese control también trae responsabilidades.

Tener acceso root no es solamente una ventaja

Cuando alguien empieza puede pensar:

Con root puedo hacer cualquier cosa.

Correcto.

Incluido romper cualquier cosa.

Con permisos administrativos podemos:

• Eliminar archivos críticos.

• Cambiar configuraciones.

• Bloquear conexiones.

• Exponer servicios.

• Romper permisos.

• Desactivar medidas de seguridad.

Por eso no contrataría un VPS sin administración únicamente porque cuesta poco o parece más profesional.

¿Qué es un servidor dedicado?

En un servidor dedicado normalmente disponemos de una máquina física destinada a nuestro uso según las condiciones del proveedor.

Esto puede proporcionar:

• Mayor aislamiento.

• Recursos físicos dedicados.

• Más posibilidades de configuración.

• Control sobre determinadas características.

Pero tampoco significa automáticamente que nuestra web vaya a cargar más rápido.

Una aplicación mal optimizada seguirá teniendo problemas en un servidor potente.

Más potencia no arregla todo

Imaginemos una aplicación que realiza una consulta extremadamente ineficiente cada vez que alguien visita una página.

Podemos aumentar:

CPU

y:

RAM

y probablemente mejorar temporalmente la situación.

Pero seguimos teniendo una consulta deficiente.

Es parecido a solucionar un coche que consume demasiado instalando un depósito más grande.

Podemos recorrer más distancia antes de repostar, pero no hemos solucionado el problema original.

¿Qué es la CPU de un servidor?

La CPU ejecuta instrucciones y realiza procesamiento.

Una aplicación puede consumir CPU realizando tareas como:

• Ejecutar PHP.

• Comprimir información.

• Procesar imágenes.

• Ejecutar consultas.

• Generar páginas.

• Realizar cálculos.

• Procesar trabajos en segundo plano.

Si el procesador permanece saturado, el rendimiento puede deteriorarse.

Pero antes de comprar más CPU necesitamos averiguar qué está provocando el consumo.

¿Qué es la RAM?

La memoria RAM permite mantener información accesible rápidamente mientras los procesos están funcionando.

Los servicios del servidor consumen memoria.

Por ejemplo:

• Sistema operativo.

• Servidor web.

• PHP.

• Base de datos.

• Caché.

• Procesos auxiliares.

Si configuramos demasiados servicios para la memoria disponible podemos tener problemas.

¿Cuánta RAM necesita una web?

No existe una cifra universal.

Depende de:

• Aplicación.

• Tráfico.

• Base de datos.

• Número de procesos.

• Caché.

• Plugins.

• Servicios adicionales.

• Configuración.

Una web estática sencilla y una tienda WooCommerce con muchos usuarios concurrentes no tienen las mismas necesidades.

No elegiría servidor únicamente utilizando una tabla genérica de:

X visitas = X GB de RAM.

Hay demasiadas variables.

¿Qué es el almacenamiento?

El servidor necesita almacenar información.

Por ejemplo:

• Sistema operativo.

• Código.

• Imágenes.

• Vídeos.

• Logs.

• Bases de datos.

• Backups, cuando corresponda.

• Archivos temporales.

Actualmente encontraremos frecuentemente almacenamiento SSD y NVMe.

Pero nuevamente, no me fijaría solamente en una palabra comercial.

También importan rendimiento real, capacidad, redundancia y arquitectura.

¿Qué es el ancho de banda?

El ancho de banda está relacionado con la cantidad/capacidad de transferencia de datos a través de la red.

Si tenemos una página que sirve archivos muy pesados a muchísimos usuarios, podemos transferir una cantidad considerable de información.

No es lo mismo una web donde cada página pesa 500 KB que una plataforma que entrega vídeos de varios gigabytes.

Por eso las necesidades de red dependen muchísimo del proyecto.

¿Qué significa tráfico ilimitado?

Cuando un proveedor utiliza palabras como:

ilimitado

leeríamos las condiciones.

En infraestructura siempre existen límites físicos o políticas de uso.

Puede significar que no existe una cuota sencilla de transferencia mensual, pero puede haber otras restricciones relacionadas con:

• Velocidad.

• Recursos.

• Uso razonable.

• CPU.

• Procesos.

• Almacenamiento.

No asumiría que “ilimitado” significa literalmente recursos infinitos.

¿Qué es Apache?

Apache HTTP Server es uno de los servidores web más conocidos.

Durante años ha tenido una presencia enorme en hosting y aplicaciones web.

Permite recibir peticiones y servir contenido, además de trabajar con diferentes configuraciones y módulos.

Muchos usuarios de WordPress han utilizado Apache sin saberlo.

¿Qué es Nginx?

Nginx es otro servidor web muy conocido.

Además de servir contenido web puede utilizarse en arquitecturas como proxy inverso y para otras funciones relacionadas con tráfico HTTP.

Es frecuente encontrarlo en servidores modernos y arquitecturas de alto tráfico.

Apache vs Nginx: ¿cuál es mejor?

No respondería:

Nginx siempre.

Ni:

Apache siempre.

Depende de:

• Aplicación.

• Arquitectura.

• Configuración.

• Conocimientos.

• Compatibilidad.

• Infraestructura.

Ambos pueden funcionar perfectamente en multitud de proyectos.

Una mala configuración de Nginx no es automáticamente mejor que una buena configuración de Apache.

¿Qué es LiteSpeed?

También podemos encontrarnos LiteSpeed en muchos proveedores de hosting.

Es otro servidor web que tiene bastante presencia especialmente en el ecosistema de alojamiento y WordPress.

Existen además soluciones de caché asociadas a este ecosistema que muchos usuarios de WordPress reconocerán.

Pero nuevamente:

utilizar determinada tecnología no garantiza por sí sola una web rápida.

El rendimiento depende del conjunto.

¿Qué es un reverse proxy?

Un proxy inverso puede colocarse delante de nuestra aplicación o servidor backend.

El usuario realiza una petición.

El proxy la recibe.

Después puede enviarla al servicio correspondiente.

Esto permite construir arquitecturas donde diferentes capas gestionan:

• TLS.

• Caché.

• Balanceo.

• Compresión.

• Enrutamiento.

• Seguridad.

• Diferentes aplicaciones.

Nginx, por ejemplo, puede utilizarse en este tipo de configuración.

¿Qué es localhost?

Cuando empezamos a administrar servidores aparece continuamente:

localhost

Hace referencia, en términos generales, al propio sistema.

También encontraremos habitualmente:

127.0.0.1

para IPv4 loopback.

Si una base de datos solamente escucha localmente, nuestra aplicación dentro del mismo servidor puede conectarse a ella sin necesidad de exponer el servicio directamente a Internet.

Esto puede tener ventajas importantes desde el punto de vista de seguridad.

No abras puertos porque sí

Un servidor conectado a Internet puede tener diferentes servicios escuchando en determinados puertos.

No necesitamos exponer públicamente todo.

Si un servicio solamente debe ser utilizado internamente, preguntaría:

¿por qué debería poder conectarse cualquier persona desde Internet?

Cuanto menor sea nuestra superficie de exposición, mejor.

¿Qué es un puerto?

Los puertos permiten diferenciar servicios de red dentro de un sistema.

Algunos números aparecen constantemente.

Por ejemplo:

80

se asocia habitualmente con HTTP.

443

con HTTPS.

22

con SSH.

Pero saber los números no es suficiente.

Lo importante es entender qué servicio tenemos escuchando, quién necesita acceder y cómo está protegido.

¿Qué es SSH?

SSH permite administrar sistemas remotamente mediante una conexión segura.

Cuando contratamos determinados VPS podemos recibir:

• IP.

• Usuario.

• Método de autenticación.

y conectarnos mediante SSH.

Desde ahí podemos utilizar la terminal para administrar el servidor.

Esto proporciona muchísimo control.

Y también significa que debemos proteger correctamente el acceso.

Contraseñas débiles en SSH son una mala idea

Un servidor público puede recibir intentos automatizados de acceso.

No necesitamos ser una empresa famosa para que ocurra.

Bots recorren Internet buscando servicios expuestos.

Por eso debemos utilizar mecanismos de autenticación adecuados y una configuración segura.

No confiaría en:

admin / admin123

porque “nadie conoce mi IP”.

¿Qué son las claves SSH?

Las claves SSH permiten utilizar criptografía de clave pública para autenticarnos.

Tenemos una clave privada que debemos proteger y una parte pública que puede configurarse en el servidor.

Esto puede proporcionar un mecanismo muy útil para administrar accesos.

La clave privada debe tratarse como una credencial sensible.

No la publicaría en:

• GitHub.

• Foros.

• Capturas.

• Mensajes.

• Documentación pública.

¿Qué es un firewall?

Un firewall permite controlar determinado tráfico de red según reglas.

Podemos decidir qué conexiones están permitidas y cuáles no.

Por ejemplo, un servidor web público necesita aceptar tráfico web.

Pero quizá nuestra base de datos no debería estar accesible directamente desde cualquier IP de Internet.

La configuración dependerá completamente de nuestra arquitectura.

Firewall no significa servidor invulnerable

Es una capa.

No sustituye:

• Actualizaciones.

• Contraseñas seguras.

• Permisos.

• Backups.

• Configuración correcta.

• Seguridad de la aplicación.

Podemos tener un firewall perfectamente configurado y una aplicación vulnerable.

La seguridad funciona por capas.

Actualizar el servidor es importante

El sistema operativo y sus paquetes reciben actualizaciones.

Algunas corrigen:

• Bugs.

• Vulnerabilidades.

• Problemas de compatibilidad.

Si administramos nuestro propio servidor necesitamos tener una estrategia para mantenerlo.

No dejaría una máquina pública durante cinco años sin actualizar porque:

Si funciona, no lo toques.

Ese enfoque puede terminar bastante mal en sistemas conectados a Internet.

Pero tampoco actualizaría producción sin pensar

El extremo contrario tampoco es ideal.

En una infraestructura importante conviene conocer qué vamos a actualizar y tener mecanismos de recuperación.

Una actualización puede introducir cambios incompatibles.

Dependiendo del proyecto utilizaría:

• Backups.

• Snapshots.

• Staging.

• Ventanas de mantenimiento.

• Monitorización.

La estrategia depende de la importancia del servicio.

¿Qué es Linux?

Gran parte de los servidores web utilizan sistemas basados en Linux.

Cuando empezamos a administrar VPS aparecen distribuciones como:

• Debian.

• Ubuntu.

• AlmaLinux.

• Rocky Linux.

No necesitamos convertirnos inmediatamente en administradores de sistemas profesionales.

Pero aprender fundamentos de Linux resulta extremadamente útil si queremos gestionar servidores.

Comandos básicos que terminarás utilizando

Cuando trabajamos mediante terminal encontramos comandos para:

• Navegar entre directorios.

• Listar archivos.

• Copiar.

• Mover.

• Eliminar.

• Consultar procesos.

• Ver espacio.

• Revisar memoria.

• Leer logs.

• Administrar servicios.

Aquí recomiendo bastante prudencia.

En una interfaz gráfica podemos recibir varias advertencias antes de eliminar algo.

En terminal un comando con permisos suficientes puede hacer exactamente lo que le pedimos.

Aunque lo que le hayamos pedido sea una barbaridad.

Cuidado con copiar comandos de Internet

Esto es especialmente importante para principiantes.

Encontramos un problema.

Buscamos en Google.

Alguien dice:

Ejecuta esto como root.

No sabemos qué hace.

Lo pegamos.

No lo haría.

Antes intentaría entender:

• Qué comando es.

• Qué archivos modifica.

• Qué permisos utiliza.

• Si instala software.

• Si descarga scripts.

• Si elimina información.

Lo mismo se aplica al código generado por inteligencia artificial.

¿Qué es root?

En sistemas Unix/Linux, root es el usuario con privilegios administrativos muy elevados.

Puede realizar prácticamente cualquier operación sobre el sistema.

Por eso utilizar root continuamente aumenta el impacto de un error.

En muchos entornos es preferible trabajar con usuarios y permisos adecuados y elevar privilegios únicamente cuando sea necesario.

Permisos de archivos

Los permisos determinan quién puede:

• Leer.

• Escribir.

• Ejecutar.

determinados archivos y directorios.

Cuando una aplicación muestra:

Permission denied

la solución no debería ser automáticamente:

Doy todos los permisos a todo.

Configuraciones excesivamente permisivas pueden crear problemas de seguridad.

Debemos entender qué usuario ejecuta cada servicio y qué acceso necesita realmente.

¿Qué es PHP-FPM?

En servidores donde ejecutamos aplicaciones PHP podemos encontrarnos con PHP-FPM.

Gestiona procesos PHP que pueden trabajar junto al servidor web.

Cuando una web PHP recibe tráfico, la configuración de estos procesos puede influir en:

• Capacidad.

• Consumo de memoria.

• Concurrencia.

• Rendimiento.

Aumentar indiscriminadamente el número de procesos tampoco es una solución mágica.

Cada proceso puede consumir recursos.

¿Por qué aparece un error 502?

Un 502 Bad Gateway puede aparecer cuando un servidor que actúa como gateway o proxy recibe una respuesta no válida del servicio al que intenta comunicarse.

Por ejemplo, podríamos tener:

Nginx → aplicación/PHP

y existir algún problema en esa comunicación.

Pero un 502 no tiene una única causa universal.

Hay que revisar logs y arquitectura.

¿Y un error 503?

Un 503 Service Unavailable indica que el servicio no está disponible para atender la solicitud en ese momento.

Puede estar relacionado con:

• Mantenimiento.

• Saturación.

• Servicios detenidos.

• Problemas temporales.

Nuevamente, el código nos da una pista.

No un diagnóstico completo.

Error 500

El famoso:

500 Internal Server Error

indica que algo ha fallado en el servidor al procesar la solicitud.

Para un usuario:

La web está rota.

Para nosotros debería significar:

Necesito mirar los logs.

Puede estar relacionado con código, configuración, permisos y muchas otras causas.

Los logs son nuestros amigos

Cuando algo falla, revisar registros puede ahorrarnos muchísimo tiempo.

Podemos encontrar logs de:

• Servidor web.

• PHP.

• Sistema.

• Aplicación.

• Base de datos.

• Firewall.

• Servicios.

En lugar de cambiar diez configuraciones al azar, intentaría localizar primero qué error se está produciendo.

No publiques logs completos sin revisarlos

Los logs pueden contener información sensible.

Antes de compartirlos en un foro comprobaría que no aparecen:

• IPs que no debamos divulgar.

• Tokens.

• Cookies.

• Credenciales.

• Rutas sensibles.

• Datos personales.

• Cabeceras de autenticación.

Podemos compartir el fragmento relevante eliminando información que no sea necesaria para resolver el problema.

¿Qué es el uptime?

El uptime representa el tiempo que un servicio o sistema permanece disponible.

Los proveedores pueden hablar de porcentajes como:

99,9 %

Pero conviene comprender qué significa realmente y qué cubre la garantía concreta del servicio.

Además, un servidor puede estar encendido y nuestra aplicación estar rota.

Por eso monitorizar solamente si la máquina responde no siempre es suficiente.

Monitorización

Si tenemos una web importante, no esperaría necesariamente a que un cliente me escriba:

Tu página lleva tres horas caída.

Podemos monitorizar diferentes aspectos:

• Disponibilidad.

• Tiempo de respuesta.

• CPU.

• RAM.

• Disco.

• Servicios.

• Errores.

• Certificados.

• Base de datos.

La profundidad necesaria dependerá del proyecto.

El disco lleno puede tirar una web

Este problema es más habitual de lo que parece.

Los logs crecen.

Los backups se acumulan.

Subimos archivos.

La base aumenta.

Y un día:

0 espacio disponible.

A partir de ahí pueden empezar comportamientos extraños.

Por eso monitorizar almacenamiento resulta importante.

Los logs también pueden llenar el disco

Un error que se repite miles de veces puede generar archivos enormes.

No basta con:

borrar el log.

Tenemos que descubrir por qué está creciendo.

También existen sistemas de rotación que permiten gestionar archivos de registro evitando que crezcan indefinidamente.

¿Dónde deben guardarse los backups?

No confiaría únicamente en copias almacenadas dentro del mismo servidor que queremos proteger.

Imaginemos:

servidor falla completamente → servidor y todos sus backups desaparecen juntos.

Una estrategia más robusta puede incluir copias en ubicaciones separadas.

Lo importante es pensar qué escenarios queremos poder recuperar.

Snapshot y backup no siempre son lo mismo

Un snapshot puede resultar muy útil para recuperar rápidamente el estado de una máquina o volumen según la plataforma utilizada.

Pero no asumiría automáticamente que sustituye toda nuestra estrategia de backup.

Debemos conocer:

• Dónde se almacena.

• Qué ocurre si eliminamos el servidor.

• Cuánto se conserva.

• Cómo se restaura.

• Qué dependencias tiene.

La palabra “snapshot” por sí sola no garantiza nada.

¿Qué es una base de datos en otro servidor?

En proyectos pequeños podemos tener:

web + PHP + base de datos

en la misma máquina.

A medida que cambian las necesidades, podemos separar servicios.

Por ejemplo:

Servidor web

↓

Servidor de aplicación

↓

Servidor de base de datos

Esto permite escalar y administrar componentes de forma diferente.

Pero también añade complejidad de red, seguridad y mantenimiento.

No separaría servicios solamente para que la arquitectura parezca más profesional.

¿Qué es un balanceador de carga?

Imaginemos que un único servidor ya no es suficiente.

Podemos tener varios servidores capaces de atender solicitudes.

Un balanceador puede distribuir tráfico entre ellos.

Conceptualmente:

Usuarios

↓

Balanceador

↓

Servidor A / Servidor B / Servidor C

Esto puede ayudar con capacidad y disponibilidad.

Pero requiere que nuestra aplicación esté preparada para funcionar correctamente en ese entorno.

Añadir servidores no arregla una aplicación que no puede escalar horizontalmente

Supongamos que guardamos archivos de sesión exclusivamente en el disco local del servidor A.

El usuario inicia sesión.

La siguiente petición termina en servidor B.

Servidor B no conoce esa sesión.

Tenemos un problema.

Cuando distribuimos una aplicación debemos pensar qué información es local y qué debe compartirse.

Escalar infraestructura obliga muchas veces a revisar arquitectura.

¿Qué es una CDN?

Una CDN puede distribuir determinados recursos desde diferentes ubicaciones y reducir la distancia o carga asociada a servir contenido.

Puede resultar especialmente útil para:

• Imágenes.

• CSS.

• JavaScript.

• Vídeo.

• Archivos estáticos.

Dependiendo del proveedor también puede ofrecer otras funciones.

Pero una CDN no convierte automáticamente una aplicación lenta en rápida.

Si nuestro backend tarda cinco segundos en generar cada página, tenemos que investigar también ese problema.

Servidor cerca del usuario

La distancia física y de red puede influir en la latencia.

Si absolutamente todos nuestros clientes están en España, puede tener sentido considerar infraestructura bien conectada con ese público.

Pero no elegiría proveedor únicamente mirando el país escrito en una ficha.

Importan también:

• Red.

• Peering.

• Calidad de infraestructura.

• CDN.

• Arquitectura.

• Aplicación.

Hay que mirar el conjunto.

¿Qué es latencia?

La latencia representa el tiempo que tarda la comunicación entre puntos.

Aunque nuestro servidor procese una petición rápidamente, la información necesita viajar por la red.

En aplicaciones muy sensibles al tiempo, unos milisegundos pueden importar bastante.

En otras, optimizar primero una consulta que tarda tres segundos será muchísimo más importante que ahorrar 10 ms de red.

¿Qué servidor necesita WordPress?

La respuesta depende del WordPress.

Un blog con pocas visitas no necesita lo mismo que:

• Una tienda grande.

• Un membership.

• Una comunidad.

• Una web con miles de usuarios conectados.

Antes de ampliar servidor intentaría identificar el cuello de botella.

Puede estar en:

• PHP.

• MySQL/MariaDB.

• Plugins.

• Consultas.

• Caché.

• Recursos externos.

• CPU.

• RAM.

No existe un “servidor perfecto para WordPress” independiente del proyecto.

WooCommerce aumenta la complejidad

Una tienda necesita gestionar contenido dinámico:

• Carritos.

• Usuarios.

• Sesiones.

• Pedidos.

• Inventario.

• Checkout.

• Pagos.

No podemos almacenar en caché indiscriminadamente absolutamente todo como si fuese una página estática.

Por eso una tienda puede necesitar más atención en infraestructura y configuración que un blog sencillo.

¿Cuándo cambiaría de servidor?

No migraría porque alguien me diga:

Tu web debería estar en un VPS.

Migraría cuando exista una razón.

Por ejemplo:

• Falta de recursos.

• Necesidad de configuración específica.

• Problemas continuos de rendimiento.

• Necesidad de mayor control.

• Crecimiento.

• Requisitos técnicos.

• Problemas con el proveedor.

Primero mediría.

Después decidiría.

¿Cuándo NO administraría mi propio servidor?

Si mi negocio depende de una web y no tengo conocimientos ni tiempo para administrar sistemas, valoraría seriamente un servicio gestionado.

Administrar un servidor implica ocuparse de cuestiones como:

• Actualizaciones.

• Seguridad.

• Backups.

• Monitorización.

• Incidencias.

• Configuración.

• Recuperación.

Ahorrar unos euros al mes puede salir caro si una caída dura dos días porque no sabemos cómo recuperarla.

Gestionado vs no gestionado

Un VPS no gestionado normalmente nos da mucha responsabilidad sobre el sistema.

Un servicio gestionado puede incluir diferentes niveles de soporte y administración.

Pero “gestionado” no significa exactamente lo mismo en todos los proveedores.

Antes de contratar preguntaría:

• ¿Qué administran?

• ¿Qué actualizan?

• ¿Qué monitorizan?

• ¿Qué ocurre si la web cae?

• ¿Gestionan el servidor web?

• ¿Gestionan la base de datos?

• ¿Hacen backups?

• ¿Restauran copias?

• ¿Ayudan con seguridad?

Leer las condiciones evita sorpresas.

Servidor barato vs servidor bueno

No escogería exclusivamente por precio.

Pero tampoco asumiría que más caro significa automáticamente mejor.

Evaluaría:

recursos + soporte + red + almacenamiento + backups + ubicación + administración + reputación

según las necesidades reales.

Para un proyecto pequeño, gastar 300 € mensuales en infraestructura puede ser absurdo.

Para una tienda que factura cantidades importantes, ahorrar 10 € sacrificando fiabilidad también puede serlo.

¿Necesito aprender servidores si soy webmaster?

No necesariamente al nivel de un administrador de sistemas.

Pero entender los fundamentos ayuda muchísimo.

Conceptos como:

• DNS.

• HTTP.

• HTTPS.

• CPU.

• RAM.

• Disco.

• PHP.

• Base de datos.

• Caché.

• Logs.

• Backups.

permiten diagnosticar problemas con bastante más criterio.

Dejamos de pensar:

La web está lenta.

y empezamos a preguntar:

¿Está tardando el servidor en responder o el problema aparece después en el navegador?

Eso cambia completamente cómo investigamos.

Ruta para aprender administración de servidores

Si quisiera empezar desde cero seguiría algo parecido a:

1. Linux básico

Archivos, usuarios, permisos y procesos.

2. Redes

IP, puertos, DNS y conexiones.

3. SSH

Administración remota.

4. Servidor web

Apache o Nginx.

5. HTTPS

Certificados y TLS.

6. PHP o runtime correspondiente

Cómo se ejecuta nuestra aplicación.

7. Bases de datos

Instalación, acceso y backups.

8. Firewall

Exposición de servicios.

9. Logs

Diagnóstico.

10. Backups y restauración

Recuperación.

11. Monitorización

Detectar problemas antes de que sean graves.

Y practicaría en un servidor destinado específicamente a pruebas.

No aprendería directamente sobre un servidor de producción

Si tenemos una tienda que factura todos los días, probablemente no sea el lugar ideal para experimentar con nuestro primer:

systemctl

nuestra primera configuración de Nginx o nuestros primeros permisos Linux.

Crearía un entorno separado.

Romper servidores de prueba es una excelente forma de aprender.

Romper producción un viernes por la noche es bastante menos divertido.

Conclusión

Un servidor web es una de las piezas fundamentales que permiten que nuestras páginas y aplicaciones estén disponibles en Internet.

Cuando un usuario visita una web podemos tener detrás:

DNS → servidor web → aplicación → PHP → base de datos → respuesta

y posiblemente muchas más capas.

No necesitamos conocer toda la administración de sistemas para publicar una página.

Un hosting gestionado puede encargarse de gran parte del trabajo.

Pero entender cómo funcionan servidores, recursos, HTTP, logs, backups y servicios nos ayuda muchísimo cuando administramos proyectos web.

Y sobre todo nos permite evitar una de las formas más caras de solucionar problemas:

cambiar cosas al azar hasta que aparentemente vuelva a funcionar.

Primero medir.

Después revisar logs.

Identificar el cuello de botella.

Y finalmente actuar.

¿Utilizáis hosting compartido, VPS o servidor dedicado en vuestros proyectos? ¿En qué momento os disteis cuenta de que necesitabais cambiar de infraestructura?