Nginx trys to download file instead of displaying - nginx

Question

I install Nginx and have a subdomain and domain. The subdomain has php5-fpm and wordpress. It works fine and is in one sites-available file symlinked to sites-enabled. The domain doesn't have php and has a file also symlinked. Even after restarting the server when I go to the domain it tries to download the html file. Here is my sites-available page for the domain:
server {
server_name www.example.us;
rewrite ^(.*) http://example.us$1 permanent;
}
server {
listen 80;
server_name example.us;
root /var/www/example;
index index.php;
autoindex on;
autoindex_exact_size off;
include /etc/nginx/security;
# Logging --
access_log /var/log/nginx/example.us.access.log;
error_log /var/log/nginx/example.us.error.log notice;
# serve static files directly
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt)$ {
access_log off;
expires max;
}
# location ~ \.php$ {
# try_files $uri =404;
# fastcgi_pass unix:/var/run/php5-fpm/example.us.socket;
# fastcgi_index index.php;
# include /etc/nginx/fastcgi_params;
# }
}
The nginx.conf file is:
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
# Basic Settings
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Logging Settings
log_format gzip '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
access_log /var/log/nginx/access.log gzip buffer=32k;
error_log /var/log/nginx/error.log notice;
# Gzip Settings
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
# Virtual Host Configs
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

Answer 1

Remove default_type application/octet-stream;. This lines makes the browser think it's some binary data and not HTML.

Answer 2

As others noted, this is the line that causes your trouble:
default_type application/octet-stream;
This line overrides the line before it and tells Nginx to send any response as generic binary data. And, since browsers cannot do anything specific with binary data, they just download it as a file.
Removing or commenting that line, as well as the line above:
#include /etc/nginx/mime.types;
#default_type application/octet-stream;
should work, as default Nginx behaviour is to send everything as text/plain and browsers are smart enough to handle HTML/CSS/JS this way.
Despite that I wouldn't recommend such solution, as you may need to serve different types of content from your server, i.e. pictures, mp3's, binaries, etc.
Here's a better solution:
First, check that file /etc/nginx/mime.types; actually exists and accessible to read for the user that runs nginx.
Then, check that the file actually contains types { ... } declarations. That file comes packaged with Nginx and contains sensible defaults for mime-types to filename extensions mapping. If something is wrong with the file you can copy-paste its content from this gist:
https://gist.github.com/kondratovbr/dd34feba1d63bd468ded4ee70e59ea07
And finally, in nginx.conf change
default_type application/octet-stream;
to
default_type text/html;
Now Nginx will serve each type of content based on filename extensions. And if none provided, which is the case with some backend systems/apps, - will try to serve HTML.
Notice that you may want to change some of that defaults. For example, with that setting:
types {
audio/mpeg mp3;
}
browsers will usually try to playback the song rather than straight up download it. Which can be changed, if needed, by declaring:
types {
application/octet-stream mp3;
}

Answer 3

Also try clearing the cache for that site. I was having this problem in Firefox but rolling back to older configs wasn't working