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.