Testing a virtual hosted NGINX site
–-
I'm having a bit of difficulty testing a virtually hosted site on NGINX. I'm in the process of updating a website for a client. It's currently hosted elsewhere, and the domain name points to that other host. I've installed the new version of the site on my linode, and have modified my desktop's /etc/hosts file to include:
my.linode.ip mydomain.com
Yet, when I try accessing mydomain.com, all I get is a blank screen. No HTML is rendered or sent, but there's also no error in any of my logs. My server configuration is:
/opt/nginx/nginx.conf:
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include 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 logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
include /opt/nginx/sites-enabled/*; # <-- I dynamically include all virtually hosted sites here
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#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 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;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
And my virutal host file is:
server {
listen 80;
server_name mydomain.com;
root /home/me/www/mydomain/web;
location / {
try_files $uri /app.php$is_args$args;
}
# DEV - remove when things are working
location ~ ^/(app_dev|config)\.php(/|$) {
fastcgi_pass unix:/var/run/php/php7.1-fpm-mydomain.sock;
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
}
# PROD
location ~ ^/app\.php(/|$) {
fastcgi_pass unix:/var/run/php/php7.1-fpm-mydomain.sock;
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
internal;
}
location ~ /.well-known {
allow all;
}
location ~ \.php$ {
return 404;
}
error_log /var/log/nginx/mydomain_error.log;
access_log /var/log/nginx/mydomain_access.log;
}
The access log has entries that look like:
173.44.91.36 - - [26/Jul/2017:18:34:10 -0400] "GET / HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0"
And, again, no errors in any log (NGINX, PHP-FPM, or Symfony).
All of this makes me wonder if it's not matching on the sent in domain name at all. But, I would think that it wouldn't return a 200 status code if that was the case.
For clarity's sake, the domain name itself still points to the old hosting/version of the site. I didn't want to flip the switch to my linode until I was sure everything was working correctly.
Any ideas? This lack of error log clues to track down the problem is frustrating.