Cómo solucionar problemas comunes de sitios en un servidor Linux

Introducción

Todo el mundo tiene problemas con su servidor o sitio web en algún momento. Saber dónde buscar cuando se encuentra con un problema y qué componentes son los posibles culpables le ayudará a solucionar estos problemas lo más rápido y contundentemente posible.

En esta guía, comprenderá cómo solucionar estos problemas para que su sitio vuelva a funcionar.

¿Qué tipos de problemas son típicos?

La mayoría de los problemas que encontrará al intentar poner en funcionamiento su sitio caen dentro de un espectro predecible.

Analizaremos estos aspectos con más profundidad en las secciones siguientes, pero por ahora, aquí hay una lista de verificación de elementos a tener en cuenta:

• ¿Está instalado su servidor web?
• ¿Está funcionando el servidor web?
• ¿Es correcta la sintaxis de los archivos de configuración de su servidor web?
• ¿Los puertos que configuraste están abiertos (no bloqueados por un firewall)?
• ¿Su configuración de DNS le está dirigiendo al lugar correcto?
• ¿La raíz del documento apunta a la ubicación de sus archivos?
• ¿Su servidor web está sirviendo los archivos de índice correctos?
• ¿Son correctos los permisos y la propiedad de las estructuras de archivos y directorios?
• ¿Está restringiendo el acceso a través de sus archivos de configuración?
• Si tiene un backend de base de datos, ¿está en ejecución?
• ¿Puede su sitio conectarse a la base de datos con éxito?

Estos son algunos de los problemas más comunes que encuentran los administradores cuando un sitio no funciona correctamente. El problema exacto se puede identificar si se consultan los archivos de registro de los diferentes componentes y las páginas de error que se muestran en el navegador.

A continuación, repasaremos cada uno de estos escenarios para que puedas asegurarte de que tus servicios estén configurados correctamente.

Revisar los registros

Antes de intentar localizar un problema a ciegas, intente comprobar los registros de su servidor web y de los componentes relacionados. Por lo general, estos se encuentran /var/logen un subdirectorio específico del servicio.

Por ejemplo, si tiene un servidor Apache ejecutándose en un servidor Ubuntu, de manera predeterminada los registros se guardarán en /var/log/apache2. Revise los archivos en este directorio para ver qué tipo de mensajes de error se están generando. Si tiene un backend de base de datos que le está dando problemas, es probable que /var/logtambién guarde sus registros.

Otras cosas que se deben comprobar son si los propios procesos dejan mensajes de error cuando se inician los servicios. Si se intenta visitar una página web y se obtiene un error, la página de error también puede contener pistas (aunque no tan específicas como las líneas de los archivos de registro).

Utilice un motor de búsqueda para intentar encontrar información relevante que le oriente en la dirección correcta. En muchos casos, puede resultar útil pegar un fragmento de sus registros directamente en un motor de búsqueda para encontrar otros ejemplos del mismo problema. Los pasos que se indican a continuación pueden ayudarle a solucionar el problema en mayor profundidad.

¿Está instalado su servidor web?

Lo primero que probablemente necesitará para ofrecer sus sitios correctamente es un servidor web. En algunos casos, sus páginas web pueden ser servidas directamente por un contenedor Docker o alguna otra aplicación, y en realidad no necesitará instalar un servidor web dedicado, pero la mayoría de las implementaciones incluirán al menos uno.

La mayoría de las personas habrán instalado un servidor antes de llegar a este punto, pero hay algunas situaciones en las que es posible que hayas desinstalado el servidor accidentalmente al realizar otras operaciones de paquetes.

Si está en un sistema Ubuntu o Debian y necesita instalar el servidor web Apache, puede escribir:

sudo apt-get update
sudo apt-get install apache2

En estos sistemas, el proceso Apache se llama apache2.

Si está ejecutando Ubuntu o Debian y desea el servidor web Nginx, puede escribir:

sudo apt-get update
sudo apt-get install nginx

En estos sistemas, el proceso Nginx se llama nginx.

Si está ejecutando RHEL, Rocky Linux o Fedora y necesita utilizar el servidor web Apache, puede escribir:

sudo dnf install httpd

En estos sistemas, el proceso Apache se llama httpd.

Si está ejecutando RHEL, Rocky Linux o Fedora y desea utilizar Nginx, puede escribir lo siguiente. Nuevamente, elimine “sudo” si ha iniciado sesión como root:

sudo dnf install nginx

En estos sistemas, el proceso Nginx se llama nginx. A diferencia de Ubuntu, Nginx no se inicia automáticamente después de instalarse en estas distribuciones basadas en RPM. Siga leyendo para saber cómo iniciarlo.

¿Está funcionando su servidor web?

Ahora que está seguro de que su servidor está instalado, ¿está funcionando?

Hay muchas formas de averiguar si el servicio está en funcionamiento o no. Un método que es bastante multiplataforma es utilizar el netstatcomando.

Si ejecuta netstatcon los -pluntindicadores, se le indicarán todos los procesos que están utilizando puertos en el servidor. Para obtener más información sobre cómo ejecutar netstat, puede consultar Cómo usar Top, Netstat, Du y otras herramientas para monitorear los recursos del servidor . Luego, puede grepobtener el resultado de netstatpara el nombre del proceso que está buscando:

sudo netstat -plunt | grep nginx

Outputtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      15686/nginx: mastertcp6       0      0 :::80                   :::*                    LISTEN      15686/nginx: master

Puede cambiar nginxel nombre del proceso del servidor web en su servidor. Si ve una línea como la que se muestra arriba, significa que su proceso está activo y en ejecución. Si no obtiene ningún resultado, significa que consultó el proceso incorrecto o que su servidor web no se está ejecutando.

Si su servidor web no está en ejecución, puede iniciarlo utilizando el sistema init de su distribución Linux . La mayoría del software diseñado para ejecutarse en segundo plano se registrará en el sistema init después de instalarse, de modo que pueda iniciarlo y detenerlo mediante programación. La mayoría de las distribuciones también utilizan ahora el mismo sistema init, systemdque proporciona el systemctlcomando.

Por ejemplo, puedes iniciar el nginxservicio escribiendo:

sudo systemctl start nginx

Si tu servidor web se inicia, puedes netstatvolver a consultarlo para verificar que todo esté correcto.

¿Es correcta la sintaxis del archivo de configuración del servidor web?

Si su servidor web no pudo iniciarse, esto suele ser una indicación de que sus archivos de configuración necesitan algo de atención. Tanto Apache como Nginx requieren un estricto cumplimiento de su sintaxis para que su configuración se analice correctamente.

Los archivos de configuración de los servicios del sistema normalmente se ubican dentro de un subdirectorio del /etc/directorio que lleva el nombre del proceso mismo.

Por ejemplo, puedes llegar al directorio de configuración principal de Apache en Ubuntu escribiendo:

cd /etc/apache2

El directorio de configuración de Apache en RHEL, Rocky y Fedora también refleja el nombre RHEL para ese proceso:

cd /etc/httpd

La configuración se distribuirá entre muchos archivos diferentes. Si intenta iniciar un servicio sin éxito, generalmente se producirán errores que apuntarán al archivo de configuración y a la línea donde se encontró el problema por primera vez. Puede comenzar a investigar ese archivo.

Cada uno de estos servidores web también proporciona una forma de validar la sintaxis de configuración de sus archivos.

Si está utilizando Apache, puede utilizar el comando apache2ctlo apachectlpara verificar si hay errores de sintaxis en sus archivos de configuración:

apache2ctl configtest

OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this messageSyntax OK

Syntax OKBásicamente significa que no hay errores importantes que impidan que el servidor funcione y que todos los mensajes que se imprimen antes de eso son errores menores o advertencias. En este caso, refleja Could not reliably determine the server's fully qualified domain nameuna configuración de Apache lista para usar en un servidor que aún no se ha configurado con un nombre de dominio, pero que aún debería ser accesible por su dirección IP.

Si tienes un servidor web Nginx, puedes ejecutar una prueba similar escribiendo:

sudo nginx -t

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful

Si elimina un punto y coma al final de una línea de configuración /etc/nginx/nginx.conf(un error común en las configuraciones de Nginx), recibirá un mensaje como este:

sudo nginx -t 

Outputnginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18nginx: configuration file /etc/nginx/nginx.conf test failed

Hay una cantidad no válida de argumentos porque Nginx busca un punto y coma para finalizar las declaraciones. Si no encuentra ninguno, pasa a la siguiente línea y la interpreta como argumentos adicionales para la última línea.

Puede ejecutar estas pruebas para encontrar problemas de sintaxis en sus archivos. Corrija los problemas a los que hace referencia hasta que pueda lograr que los archivos pasen la prueba.

¿Están abiertos los puertos que configuraste?

Por lo general, los servidores web se ejecutan en el puerto 80 para el tráfico web HTTP y utilizan el puerto 443 para el tráfico HTTPS cifrado con TLS/SSL. Para que los usuarios puedan acceder a su sitio, estos puertos deben ser accesibles.

Puede probar si su servidor tiene el puerto abierto ejecutándolo netcatdesde su máquina local.

Necesitarás usar la dirección IP de tu servidor remoto e indicarle qué puerto verificar, de la siguiente manera:

nc -z 111.111.111.111 80

Esto comprobará si el puerto 80 está abierto en el servidor en 111.111.111.111. Si está abierto, el comando regresará de inmediato. Si no está abierto, el comando intentará continuamente establecer una conexión, sin éxito. Puede detener este proceso presionando CTRL+Cen la ventana de terminal.

Si no se puede acceder a los puertos web, debe revisar la configuración del firewall. Es posible que deba abrir el puerto 80 o el puerto 443.

¿Su configuración de DNS le dirige al lugar correcto?

Si puede acceder a su sitio mediante su dirección IP, pero no a través de un nombre de dominio que haya configurado, es posible que necesite revisar su configuración de DNS.

Para que los visitantes puedan acceder a su sitio a través de su nombre de dominio, debe tener un registro “A” o “AAAA” que apunte a la dirección IP de su servidor en la configuración de DNS. Puede consultar el registro “A” de su dominio utilizando el hostcomando en un servidor local o:

host -t A example.com

Outputexample.com has address 93.184.216.119

La línea que se le devuelve debe coincidir con la dirección IP de su servidor. Si necesita comprobar un registro “AAAA” (para conexiones IPv6), puede escribir:

host -t AAAA example.com

Outputexample.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

Tenga en cuenta que cualquier cambio que realice en sus registros DNS puede tardar un tiempo en propagarse, según el registrador de su nombre de dominio. A veces puede ser útil utilizar un sitio como https://www.whatsmydns.net/ para comprobar cuándo se han aplicado los cambios de DNS a nivel global (normalmente, media hora más o menos). Es posible que reciba resultados inconsistentes en estas consultas después de un cambio, ya que su solicitud a menudo llegará a diferentes servidores que aún no están todos actualizados.

Si utiliza DigitalOcean, puede aprender cómo configurar los ajustes DNS para su dominio aquí.

Asegúrese de que sus archivos de configuración también manejen su dominio correctamente

Si su configuración de DNS es correcta, es posible que también desee verificar los archivos de host virtual Apache o los archivos de bloque del servidor Nginx para asegurarse de que estén configurados para responder a las solicitudes de su dominio.

En Apache, su archivo de host virtual podría verse así:

/etc/apache2/sites-enabled/000-default.conf

lt;VirtualHost *:80gt;    ServerName example.com    ServerAlias www.example.com    ServerAdmin admin@example.com    DocumentRoot /var/www/html. . .

Este host virtual está configurado para responder a cualquier solicitud en el puerto 80 para el dominio example.com.

Un fragmento similar en Nginx podría verse así:

/etc/nginx/sites-enabled/predeterminado

server {    listen 80 default_server;    listen [::]:80 default_server ipv6only=on;    root /usr/share/nginx/html;    index index.html index.htm;    server_name example.com www.example.com;. . .

Estos dos bloques están configurados para responder a los mismos tipos de solicitudes predeterminadas.

¿La raíz del documento apunta a la ubicación de sus archivos?

Otra consideración es si su servidor web está apuntando a la ubicación de archivo correcta.

Cada servidor virtual de Apache o bloque de servidor de Nginx está configurado para apuntar a un puerto o directorio local específico. Si esto no se configura correctamente, el servidor mostrará un mensaje de error cuando intente acceder a la página.

En Apache, la raíz del documento se configura a través de la DocumentRootdirectiva:

/etc/apache2/sites-enabled/predeterminado

lt;VirtualHost *:80gt;    ServerName example.com    ServerAlias www.example.com    ServerAdmin admin@example.com    DocumentRoot /var/www/html. . .

Esta línea le indica a Apache que debe buscar los archivos de este dominio en el /var/www/htmldirectorio. Si sus archivos se guardan en otro lugar, deberá modificar esta línea para que indique la ubicación correcta.

En Nginx, la rootdirectiva configura lo mismo:

/etc/nginx/sites-enabled/predeterminado

server {    listen 80 default_server;    listen [::]:80 default_server ipv6only=on;    root /usr/share/nginx/html;    index index.html index.htm;    server_name example.com www.example.com;. . .

En esta configuración, Nginx busca archivos para este dominio en el /usr/share/nginx/htmldirectorio.

¿Su servidor web está sirviendo los archivos de índice correctos?

Si la raíz de su documento es correcta y sus páginas de índice no se muestran correctamente cuando accede a su sitio o a una ubicación de directorio en su sitio, es posible que sus índices estén configurados incorrectamente.

Según la complejidad de sus aplicaciones web, muchos servidores web seguirán ofreciendo archivos de índice de forma predeterminada . Por lo general, se trata de un index.htmlarchivo o de un index.phparchivo, según su configuración.

En Apache, puede encontrar una línea en su archivo de host virtual que configura el orden de índice que se utilizará para directorios específicos de forma explícita, como esta:

/etc/apache2/sites-enabled/predeterminado

lt;Directory /var/www/htmlgt;    DirectoryIndex index.html index.phplt;/Directorygt;

Esto significa que cuando se sirve el directorio, Apache buscará un archivo llamado index.htmlprimero e intentará servir index.phpcomo respaldo si no se encuentra el primer archivo.

Puede configurar el orden en el que se entregarán los archivos de índice para todo el servidor editando el mods-enabled/dir.confarchivo, lo que establecerá los valores predeterminados para el servidor. Si su servidor no entrega un archivo de índice, asegúrese de tener un archivo de índice en su directorio que coincida con una de las opciones de su archivo.

En Nginx, la directiva que hace esto se llama indexy se usa así:

/etc/nginx/sites-enabled/predeterminado

server {    listen 80 default_server;    listen [::]:80 default_server ipv6only=on;    root /usr/share/nginx/html;    index index.html index.htm;    server_name example.com www.example.com;. . .

¿Están configurados correctamente los permisos y la propiedad?

Para que el servidor web pueda servir correctamente los archivos, debe poder leerlos y tener acceso a los directorios donde se guardan. Esto se puede controlar a través de los permisos y la propiedad de los archivos y directorios.

Para leer archivos, los directorios que contienen el contenido deben ser legibles y ejecutables por la cuenta de usuario asociada al servidor web. En Ubuntu y Debian, Apache y Nginx se ejecutan como el usuario www-dataque es miembro del www-datagrupo.

En RHEL, Rocky y Fedora, Apache se ejecuta con un usuario llamado apacheque pertenece al apachegrupo. Nginx se ejecuta con un usuario llamado nginxque forma parte del nginxgrupo.

Con esto en mente, puedes mirar los archivos y carpetas que estás alojando:

ls -l /path/to/web/root

Los directorios deben ser legibles y ejecutables por el usuario o grupo web, y los archivos deben ser legibles para poder leer el contenido. Para poder cargar, escribir o modificar contenido, los directorios deben ser además editables y los archivos también.

Para modificar la propiedad de un archivo, puede utilizar chown:

sudo chown user_owner:group_owner /path/to/file

Esto también se puede hacer con un directorio. Puedes cambiar la propiedad de un directorio y de todos los archivos que contiene pasando el -Rindicador:

sudo chown -R user_owner:group_owner /path/to/file

Para obtener más información sobre los permisos, consulte Introducción a los permisos de Linux .

¿Está restringiendo el acceso a través de sus archivos de configuración?

La configuración de su servidor web también puede estar configurada para denegar el acceso a los archivos que intenta servir.

En Apache, esto se configuraría en el archivo de host virtual para ese sitio, o a través de un .htaccessarchivo ubicado en el propio directorio.

Dentro de estos archivos, es posible restringir el acceso de diferentes maneras. Los directorios se pueden restringir de esta manera en Apache 2.4+:

/etc/apache2/sites-enabled/predeterminado

lt;Directory /usr/sharegt;    AllowOverride None    Require all deniedlt;/Directorygt;

En Nginx, estas restricciones tomarán la forma de denydirectivas y estarán ubicadas en los bloques de su servidor o en los archivos de configuración principales:

/etc/nginx/sites-enabled/predeterminado

location /usr/share {    deny all;}

Si tienes un backend de base de datos, ¿está en ejecución?

Si su sitio depende de un backend de base de datos como MySQL, PostgresSQL, MongoDB, etc., debe asegurarse de que esté activo y disponible.

Puede hacerlo de la misma manera que verificó que el servidor web estaba en ejecución. Nuevamente, puede buscar entre los procesos en ejecución con netstaty grep:

sudo netstat -plunt | grep mysql

Outputtcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

Como puede ver, el servicio se está ejecutando en esta máquina. Asegúrese de saber el nombre con el que se ejecuta el servicio cuando lo busque.

Una alternativa es buscar el puerto en el que se ejecuta el servicio. Consulte la documentación de su base de datos para encontrar el puerto predeterminado en el que se ejecuta (el puerto predeterminado de MySQL es 3356) o verifique los archivos de configuración.

Si tiene un backend de base de datos, ¿puede su sitio conectarse exitosamente?

El siguiente paso que debe seguir si está solucionando un problema con el backend de una base de datos es comprobar si puede conectarse correctamente. Esto suele implicar comprobar los archivos que lee su sitio para averiguar la información de la base de datos.

Por ejemplo, en el caso de un sitio de WordPress, la configuración de conexión a la base de datos se almacena en un archivo llamado wp-config.php. Debe comprobar que DB_NAME, DB_USER, y DB_PASSWORDsean correctos para que su sitio se conecte a la base de datos.

Puede comprobar si el archivo contiene la información correcta intentando conectarse a la base de datos manualmente desde la línea de comandos. La mayoría de las bases de datos admiten una sintaxis similar a la de MySQL:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Si no puede conectarse utilizando los valores que encontró en el archivo, es posible que necesite modificar los permisos de acceso de sus bases de datos.

Si todo lo demás falla, vuelva a verificar los registros

Revisar los registros debería ser el primer paso, pero también es un buen último paso antes de pedir más ayuda.

Si ha llegado al límite de su capacidad para solucionar problemas por su cuenta y necesita ayuda, obtendrá ayuda más relevante más rápidamente si proporciona archivos de registro y mensajes de error. Los administradores experimentados probablemente tendrán una buena idea de lo que está sucediendo si les proporciona la información que necesitan.

Conclusión

Esperamos que estos consejos para la solución de problemas le hayan ayudado a localizar y solucionar algunos de los problemas más comunes que enfrentan los administradores cuando intentan poner en funcionamiento sus sitios.

Si tiene consejos adicionales sobre cosas a comprobar y formas de resolver problemas, compártalos con otros usuarios en los comentarios.