Nginx no puede cargar archivos css


81

Recientemente decidí cambiar de Apache2 a Nginx. Instalé Nginx en mi servidor CentOS y configuré una configuración básica. Cuando intenté cargar mi sitio en el navegador (FF / Chrome), noté que el archivo css no está cargado. Revisé la consola de errores y vi este mensaje:

Error: The stylesheet http://example.com/style.css was not loaded because its MIME type, "text/html", is not "text/css".

Revisé la configuración de Nginx y todo parece estar bien:

http {
    include /etc/nginx/mime.types;
    ..........
}

El tipo de mime para los archivos css está configurado correctamente en /etc/nginx/mime.types.

text/css css;

Todo parece estar bien configurado, pero mis archivos css aún no están cargados. No tengo explicación.

Otra cosa que vale la pena mencionar. Inicialmente instalé Nginx usando repositorios epel y obtuve una versión anterior: 0.8 ... Me pareció que mi problema era un error en esa versión, así que desinstalé la versión 0.8, agregué el repositorio nginx a yum y luego instalé la última versión: 1.0. 14. Pensé que la nueva versión resolvería mi problema, pero desafortunadamente no fue así, así que me estoy quedando sin ideas.

Agradezco cualquier ayuda.

Archivos de configuración:

/etc/nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/default.conf

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
         root    /usr/share/nginx/html;
         index  index.html index.htm index.php;
         fastcgi_pass   127.0.0.1:9000;
         fastcgi_index  index.php;
         fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
         include        fastcgi_params;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

/etc/nginx/mime.types

types {
    text/html                             html htm shtml;
    text/css                              css;
    text/xml                              xml;
    image/gif                             gif;
    image/jpeg                            jpeg jpg;
    application/x-javascript              js;
    application/atom+xml                  atom;
    application/rss+xml                   rss;
    ..........................................
    other types here
    ..........................................
}

pega tu código de configuración. por lo general, ha manejado bien otros tipos de otros tipos, y se salta la parte de los archivos públicos, lo que hace que los activos como css e imágenes devuelvan errores 404 o, en su caso, errores de tipo mime
— Kristian

1
Para mi caso, tu pregunta se convirtió en una respuesta. Salud.
— Vassily

Respuestas:


95

Poner lo include /etc/nginx/mime.types;inferior en location / {lugar de lo inferior http {resolvió el problema para mí.


3
También tenga en cuenta que si está iniciando la configuración desde cero, excepto por los tipos de mime, tal vez, include mime.types;hace su trabajo, ya que (al menos en Windows, nginx 1.5.2) es solo relativo a otros archivos de configuración.
— omilke

13
También tenga en cuenta que debe actualizar completamente el sitio en su navegador, por ejemplo, usando ctrl + f5 para actualizar para evitar obtener archivos en caché con encabezados incorrectos.
— CarelZA

1
Esto es realmente fantástico.
— mtyurt

1
De hecho, esto funciona, pero ¿por qué? en http debería ser suficiente! de hecho, estuvo funcionando así durante más de un año en una caja de desarrollo y hoy simplemente dejó de funcionar sin hacer ningún cambio (sin actualizar nginx o incluso reiniciar).
— upsfeup

Señor, me salvó el día
— EAV

34

Encontré una solución alternativa en la web. Agregué a /etc/nginx/conf.d/default.conf lo siguiente:

location ~ \.css {
    add_header  Content-Type    text/css;
}
location ~ \.js {
    add_header  Content-Type    application/x-javascript;
}

El problema ahora es que una solicitud a mi archivo css no se redirige bien, como si la raíz no estuviera configurada correctamente. En error.log veo

2012/04/11 14:01:23 [error] 7260 # 0: * 2 open () "/etc/nginx//html/style.css"

Entonces, como segunda solución, agregué la raíz a cada ubicación definida. Ahora funciona, pero parece un poco redundante. ¿No se hereda la raíz de / location?


2
¿Es esto un error de nginx? Esta es la única forma en que podría hacerlo funcionar. Por cierto, estoy usando Arch Linux, nginx 1.4.1-3.
— tprk77

@ tprk77 no es un error, la respuesta aceptada es una solución alternativa, para obtener una solución adecuada, consulte mi respuesta stackoverflow.com/a/23282158/1481489
— zamnuts

23

style.cssestá siendo procesado a través de fastcgi debido a su directiva "location /". Así que es fastcgi el que está sirviendo el archivo ( nginx > fastcgi > filesystem), y no el sistema de archivos directamente ( nginx > filesystem).

Por una razón que aún no he descubierto (estoy seguro de que hay una directiva en alguna parte), NGINX aplica el tipo mime text/htmla cualquier cosa que se sirva desde fastcgi, a menos que la aplicación de backend diga explícitamente lo contrario.

El culpable es este bloque de configuración específicamente:

location / {
     root    /usr/share/nginx/html;
     index  index.html index.htm index.php;
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  index.php;
     fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
     include        fastcgi_params;
}

Debería ser:

location ~ \.php$ { # this line
     root    /usr/share/nginx/html;
     index  index.html index.htm index.php;
     fastcgi_split_path_info ^(.+\.php)(/.+)$; #this line
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  index.php;
     fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; # update this too
     include        fastcgi_params;
}

Este cambio asegura que solo *.phpse soliciten archivos de fastcgi. En este punto, NGINX aplicará el tipo MIME correcto. Si tiene alguna reescritura de URL, debe manejar esto antes de la directiva de ubicación ( location ~\.php$) para que la extensión correcta se derive y se enrute correctamente a fastcgi.

Asegúrese de consultar este artículo sobre consideraciones de seguridad adicionales al usartry_files . Dadas las implicaciones de seguridad, considero que esto es una característica y no un error.


1
esta debería ser la respuesta aceptada, ver también: forum.nginx.org/read.php?2,155222,155261#msg-155261
— Alfred Bez

1
Parece que esto sigue siendo un problema, más de 4 años después de la pregunta original. ¿Cómo se ve la configuración correcta si solo sirve contenido estático, es decir, no PHP?
— robo

10

También me encontré con este problema. Me confundió hasta que me di cuenta de lo que estaba mal:

Tu tienes esto:

include       /etc/nginx/mime.types;
default_type  application/octet-stream;

Tu quieres esto:

default_type  application/octet-stream;
include       /etc/nginx/mime.types;

parece haber un error en nginx o una deficiencia en los documentos (este podría ser el comportamiento previsto, pero es extraño)


3

Seguí algunos consejos del resto de respuestas y descubrí que estas acciones extrañas ayudaron (al menos en mi caso).

1) Agregué al bloque del servidor lo siguiente:

location ~ \.css {
 add_header Content-Type text/css;
}

Recargué nginx y obtuve esto en error.log:

2015/06/18 11:32:29 [error] 3430 # 3430: * 169 open () "/etc/nginx/html/css/mysite.css" falló (2: No existe tal archivo o directorio)

2) Eliminé las filas, recargué nginx y obtuve css funcional. No puedo explicar lo que sucedió porque mi archivo de configuración se volvió como antes.

Mi caso fue limpio xubuntu 14.04 en VirtualBox, nginx / 1.9.2, una fila 127.51.1.1 mysiteen / etc / hosts y bastante simple /etc/nginx/nginx.conf con un bloque de servidor:

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include /etc/nginx/mime.types;

    server {
        listen 80;
        server_name mysite;

        location / {
            root /home/testuser/dev/mysite/;
        }
    }
}

Ahah, lo mismo que tú xD No mime-type, agrega la regla, recarga, obtén el 404, elimina la regla, recarga, funciona con un buen tipo de mime ... Ubuntu 19.10, Nginx 1.16.1
— Doubidou

2

También me enfrento a este problema, probé muchas soluciones, pero ninguna realmente funcionó para mí

Así es como lo resolví;

Una . Otorgue la propiedad del directorio raíz del documento de dominio (digamos que mi directorio raíz es /var/www/nginx-demo) al usuario de Nginx ( www-data) para evitar problemas de permisos:

sudo chown -R www-data: /var/www/nginx-demo

B. Confirme que su bloque de servidor de host virtual cumple con este estándar (digamos que estoy usando localhostcomo mi nombre de servidor y mi raíz como /var/www/nginx-demo/website)

server {
   listen 80;
   listen [::]:80;

   server_name localhost;

   root /var/www/nginx-demo/website;
   index index.html;

   location / {
            try_files $uri $uri/ =404;
   }
}

C. Pruebe la configuración de Nginx para ver la sintaxis correcta:

sudo nginx -t

Si no hay errores en la sintaxis de configuración, la salida se verá así:

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

D. Reinicie el servicio Nginx para que los cambios surtan efecto:

sudo systemctl restart nginx

E. Actualice su sitio web en su navegador para evitar archivos en caché con encabezados incorrectos usando las teclas Ctrl + F5 o Ctrl + Fn + F5.

Eso es todo.

Espero que esto ayude.


2
  1. En su archivo nginx.conf, agregue mime.types a su httpcuerpo así:

    http {
        include /etc/nginx/mime.types;
        include /etc/nginx/conf.d/*.conf;
    }
    
  2. Ahora ve a la terminal y ejecuta lo siguiente para recargar el servidor:

    sudo nginx -s reload
    
  3. Abra su navegador web y realice una recarga completa: haga clic derecho en el botón de recarga y seleccione recarga completa. En Chrome puedes hacer Ctrl+ Shift+R


1

Para mí, esto fue un bloqueador de anuncios instalado en el navegador web. No dejaba cargar el style.css


0

Tuve el mismo problema en Windows. Lo resolví agregando: include mime.types; en http { en mi archivo nginx.conf. Entonces todavía no funcionó ... así que miré el archivo error.log y noté que estaba tratando de cargar los archivos .css y javascript desde la ruta del archivo pero con una carpeta / http entre. Ejemplo: mi .css estaba en: "C: \ Users \ pc \ Documents \ nginx-server / player-web / css / index.css" y lo estaba tomando de: "C: \ Users \ pc \ Documents \ nginx -server / html /player-web/css/index.css "Así que cambié mi carpeta player-web dentro de una carpeta html y funcionó;)


0

De hecho, me tomé mi tiempo para revisar todas las respuestas anteriores en esta página, pero fue en vano. Simplemente cambié el propietario y los permisos del directorio y subdirectorios usando el siguiente comando Cambié el propietario del directorio del proyecto web /usr/share/nginx/htmlal rootusuario que usa:

chown root /usr/share/nginx/html/mywebprojectdir/*

Y finalmente cambió los permisos de ese directorio y subdirectorios usando:

chmod 755 /usr/share/nginx/html/mywebprojectdir/*

NOTA : si se niega, puede usar sudo


0

Estaba teniendo el mismo problema y nada de lo anterior hizo ninguna diferencia para mí, lo que funcionó fue tener mi ubicación php por encima de cualquier otro bloque de ubicación.

location ~ [^/]\.php(/|$) {
fastcgi_split_path_info  ^(.+\.php)(/.+)$;
fastcgi_index            index.php;
fastcgi_pass             unix:/var/run/php/php7.3-fpm.sock;
include                  fastcgi_params;
fastcgi_param   PATH_INFO       $fastcgi_path_info;
fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
** The below is specifically for moodle **
location /dataroot/ {
internal;
alias <full_moodledata_path>; # ensure the path ends with /
}

0

El mismo problema surgió con Nginx 1.14.2 en Debian 10.6.

Se puede resolver configurando la charsetvariable. Añadiendo al bloque del servidor, debajo de la server_namedirectiva lo siguiente:

charset utf-8; # Use the appropriate charset in place of "utf-8"

-4

agregue esto a su archivo ngnix conf

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://assets.zendesk.com; font-src 'self' https://themes.googleusercontent.com; frame-src https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://tautt.zendesk.com; object-src 'none'";
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.