Currently have a pure HTML website with some embedded JS code to control flow between HTML files along with graph configuration details. The directories are as follows: html, css, fonts, img, js, sound. On my local machine, I can easily open the HTML files and navigate the site. I am using an Ubuntu Amazon EC2 instance with nginx as the reverse proxy. When running a express.js controlled website on the instance I usually just edit the nginx config file and start the app/server.js file. However, I am unsure as to how to do this with a set of static HTML files that have CSS and other assets associated with them. Below is my attempt at writing the nginx file but I'm not sure if what I'm proposing is possible.
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /var/www/website-dashboard/;
index index.html;
# Make site accessible from http://localhost/
server_name localhost;
location / {
default_type "text/html";
try_files $uri.html $uri $uri/ /index.html;
access_log off;
}
}
You shouldn't have a problem opening HTML files with NGINX - The question is, considdering you're running NGINX as a reverse proxy, what are you running as your web server?
If you're running Apache then you need to make sure it's running on port 8080 and the below NGINX configuration should meet your requirements.
upstream apachebackend {
server 127.0.0.1:8080; #apachebackend
}
server {
listen 80 default;
server_name www.domain.com domain.com;
access_log /var/log/nginx/domain.com.access.log main;
error_log /var/log/nginx/domain.com.error.log;
root /usr/share/nginx/html;
index index.html index.htm index.php;
## send request back to apachebackend ##
location / {
proxy_pass http://apachebackend;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_buffering on;
proxy_buffers 12 12k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
If you're running NGINX as your web server then you need to set it up accordingly. The default set-up should suffice, just drop your files in the default vhost directory, but I recommend setting it up correctly using separate directories and log files.
Related
i need to solve one problem. I have ngnix with public address, and i need to have access to my DB with phpmyadmin in local network by ip. I have configured it at address /usr/share/phpmyadmin following guide. At the moment i can download the php files from this directory but without execution. What i need to do to connect from browser to phpmyadmin?
This is my ngnix config:
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
server_name 192.168.1.101;
location ^~ /permanentmark/ {
alias /usr/share/phpmyadmin/;
index index.php index.html;
location ~ /pma(/.*\.php) {
include fastcgi_params;
fastcgi_param SERVER_NAME localhost;
fastcgi_param SCRIPT_FILENAME /usr/share/phpmyadmin$1;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
}
}
}
we still need is to tell Nginx to use our PHP processor for dynamic content. We do this on the server block level (server blocks are similar to Apache’s virtual hosts). Open the default Nginx server block configuration file by typing:
sudo nano /etc/nginx/sites-available/default
the Nginx default server block file looks like this:
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
We need to make some changes to this file for our site.
First, we need to add index.php as the first value of our index directive so that files named index.php are served, if available, when a directory is requested.
We can modify the server_name directive to point to our server’s domain name or public IP address.
For the actual PHP processing, we just need to uncomment a segment of the file that handles PHP requests by removing the pound symbols (#) from in front of each line. This will be the location ~.php$ location block, the included fastcgi-php.conf snippet, and the socket associated with php-fpm.
We will also uncomment the location block dealing with .htaccess files using the same method. Nginx doesn’t process these files. If any of these files happen to find their way into the document root, they should not be served to visitors.
The changes that you need to make are in the text below:
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;
server_name server_domain_or_IP;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
When you’ve made the above changes, you can save and close the file.
Test your configuration file for syntax errors by typing:
sudo nginx -t
If any errors are reported, go back and recheck your file before continuing.
When you are ready, reload Nginx to make the necessary changes:
sudo systemctl reload nginx
I am working on Ubuntu 18 and trying to render an HTML page via NGINX. Following this link I did these steps:
Created html directory using sudo mkdir -p /var/www/sample/html
Placed my Web files directory webui under the html above
Created a nginx conf file using sudo vi /etc/nginx/sites-available/sample.conf
Placed below in the sample.conf
server {
listen 80;
listen [::]:80;
root /var/www/sample/html;
index index.html index.htm index.nginx-debian.html;
server_name 123.54.67.235;
location / {
include proxy_params;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_pass http://localhost/webui/;
}
location /app {
include proxy_params;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_pass http://123.54.67.235:7000;
}
}
Created a link from it to the sites-enabled directory using sudo ln -s /etc/nginx/sites-available/sample.conf /etc/nginx/sites-enabled/
Un-commented server_names_hash_bucket_size 64;
Did sudo nginx -t. Got below message:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Did sudo systemctl restart nginx. No error came.
Now when I try to go to http://123.54.67.235 from my browser, I get nginx 500 Internal Server Error.
Not sure what's the mistake I am making as I am very new to and in-experienced with this. Can anyone suggest what's the reason for this?
UPDATE: When I go to my Nginx Error log I see below error there:
2019/05/05 05:52:51 [alert] 29779#29779: *2588 768 worker_connections are not enough while connecting to upstream, client: 123.54.67.235, server: 134.209.113.22, request: "GET /webui/webui/webui/webui/webui/webui/webui/webui/.....
Note: I am using my server's ip address in the server_name field of conf file as I do not have a domain name assigned to my server.
The proxy_pass http://localhost/webui/; statement points into the same server and generates a recursive loop by adding an endless number of /webui/ path elements. The proxy_pass directive is intended for a reverse proxy, and is used to forward requests to some other server.
To serve static content, you should use a root statement.
If the URI /foo should serve the file at /var/www/sample/html/webui/foo, use root /var/www/sample/html/webui;.
For example:
server {
...
root /var/www/sample/html/webui;
...
location / { }
location /app {
include proxy_params;
proxy_...;
proxy_pass ...;
}
}
The location / block is empty.
I am making my first go app on an Ubuntu Server. When I run my server using either an executable or simply go run main.go, I get the initial html page to render, but none of the css, images, or js. The routes also take me to a 404 page. The only thing that seems to pass is the index.html(which is named index.gohtml as a template for go)
All my assets are loaded when I run it on localhost and ip:port configuration on the server, however when I use nginx the assets are not loading in at all. I am assuming because of these factors that nginx is where I am coming across my issue.
Below is what I have so far. This is my first time using nginx so I am unaware of what is necessary to configure it properly.
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8001;
try_files $uri $uri/ =404;
}
}
You might want to separate the try_files and proxy_pass into separate locations:
location / {
try_files $uri $uri/ #proxy;
}
location #proxy {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8001;
}
If the static file does not exist, the request will be forwarded to the service running on port 8001.
See this document for details.
I know that, this question has been asked multiple times on different forums, but still I can not manage to find a solution, which solves my problem... The situation: We have a nginx, php-fpm and MySQL stack on a server. The server sits behind a nginx reverse proxy. The problem is that on the upstream server there are clean error logs and on the reverse proxy I am getting multiple messages
connect() failed (110: Connection timed out) while connecting to >upstream, client: ++++++++++, server: domain.com, request: "GET >/files/imagecache/FrontBullet/blog1/dknasda.jpg HTTP/1.1", upstream: >"http://192.168.158.142:80/files/imagecache/FrontBullet/blog1/dknasda.jpg>", host: "somedomain.com"
For some reason this error occurs every 1-5 minutes for different resources or files.
My nginx config on the reverse proxy is the following one :
user ++++;
worker_processes 3;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
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;
tcp_nodelay on;
keepalive_timeout 60s; #keeps the connection open with the client; MS default is 60.
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
gzip on;
gzip_http_version 1.1;
gzip_vary on;
gzip_comp_level 6;
gzip_proxied any;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;
gzip_buffers 16 8k;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
upstream main_upstream {
server 192.168.158.142:80 max_fails=3 fail_timeout=60s; # New Server. Sent to 192.168.90
# server 192.168.158.143:80; # HSB
keepalive 32;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name domain.com;
location / {
proxy_buffers 32 32k;
proxy_buffer_size 64k;
proxy_pass http://main_upstream;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-By $server_addr:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
send_timeout 600s;
proxy_http_version 1.1;
proxy_set_header Connection "";
client_max_body_size 32M;
client_body_buffer_size 512k;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
Any Idea why is this happening? I am using centos 7.1 abd nginx 1.6.3
Thanks in advance,
Todor
Finally found the reason and it has been clean for hours now. It turned out that there were 2 overlapping problems. The first one was the kernel dropping requests after the queue is full. Here is a nice manual about tuning the kernel linux kernel parameters - https://www.nginx.com/blog/tuning-nginx/
After the problems started we migrated the site to a new server and used DHCP to assign IP address - BIG MISTAKE. Every hour or so the dhcp restarted the network Interface. Examining the entire system log I noticed that the IP of the network interface is reassigned on regular intervals. Those intervals coincided with the bursts of errors in the log. So the solution was to go back to static IPs.
You have a upstream block like this:
upstream main_upstream {
server 192.168.158.142:80 max_fails=3 fail_timeout=60s; # New Server. Sent to 192.168.90
# server 192.168.158.143:80; # HSB
keepalive 32;
}
The first line fetches requests from 192.168.158.142:80 and stop trying after 3 fails for 60 seconds.
The second line is commented out, so it doesn't work.
Also there are other ip's listed on your other comments, which obviously won't work.
Assuming you want to fetch requests from 192.168.158.142:80 and failover to another ip 192.168.158.143:80 if it fails, this is how you do it:
upstream main_upstream {
keepalive 30;
server 192.168.158.142:80; # main server
server 192.168.158.143:80 backup; # failover
}
Or if you want to distribute the load evenly in a round robin style:
upstream main_upstream {
keepalive 30;
server 192.168.158.142:80; # server 1
server 192.168.158.143:80; # server 2
}
In both cases, make sure you can access both 192.168.158.142:80 and 192.168.158.143:80
Also bear in mind that you're using keepalive, meanning that if your backend servers are set to limit requests in any way, they might start refusing to serve requests to your frontend nginx (I will assume this is your load balancer).
I have a directory/web app that is located outside of the web root directory of my site.
Say the site is here:
/var/www/site/htdocs/
And the external app is located here:
/var/www/apps/coolapp/
My question is how can I configure nginx to map/route all requests that are like www.mysite.com/coolapp/* (asterisk being wildcard) to the external location /var/www/apps/coolapp/? For example, www.mysite.com/coolapp/test.php should server /var/www/apps/coolapp/test.php.
I have added an alias directive in production.conf that the main nginx.conf file includes. This worked fine for everything except .php files because there is another location that is catching .php files instead. So I nested a location in with the alias to catch .php files, but now nginx is telling me it can't find the .php files "404 File Not Found". Here is what production.conf currently looks like
server {
listen 80;
listen 443 ssl;
ssl_certificate /blah/blah/blah;
ssl_certificate_key /blah/blah/blah;
ssl_protocols blah blah blah;
ssl_ciphers blahblahblah;
ssl_prefer_server_ciphers blahblah;
access_log /var/log/nginx/www.mysite.com-access.log;
error_log /var/log/nginx/www.mysite.com-error.log error;
server_name mysite.com www.mysite.com;
root /var/www/site/htdocs;
include conf/magento_rewrites.conf;
include conf/magento_security.conf;
include /var/www/site/nginx/*.conf;
#-------CODE IN QUESTION-------
location /coolapp/ {
alias /var/www/apps/coolapp/;
location ~ \.php {
# Copied from "# PHP Handler" below
fastcgi_param MAGE_RUN_CODE default;
fastcgi_param MAGE_RUN_TYPE store;
fastcgi_param HTTPS $fastcgi_https;
rewrite_log on;
# By default, only handle fcgi without caching
include conf/magento_fcgi.conf;
}
}
# PHP handler
location ~ \.php {
## Catch 404s that try_files miss
if (!-e $request_filename) { rewrite / /index.php last; }
## Store code is defined in administration > Configuration > Manage Stores
fastcgi_param MAGE_RUN_CODE default;
fastcgi_param MAGE_RUN_TYPE store;
fastcgi_param HTTPS $fastcgi_https;
rewrite_log on;
# By default, only handle fcgi without caching
include conf/magento_fcgi.conf;
}
# 404s are handled by front controller
location #magefc {
rewrite ^(.*) /index.php?$query_string last;
}
# Last path match hands to magento or sets global cache-control
location / {
## Maintenance page overrides front controller
index index.html index.php;
try_files $uri $uri/ #magefc;
expires 24h;
}
}
conf/magento_fcgi.conf looks like this:
fastcgi_pass phpfpm;
## Tell the upstream who is making the request
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
# Ensure the admin panels have enough time to complete large requests ie: report generation, product import/export
proxy_read_timeout 1600s;
# Ensure PHP knows when we use HTTPS
fastcgi_param HTTPS $fastcgi_https;
## Fcgi Settings
include fastcgi_params;
fastcgi_connect_timeout 120;
fastcgi_send_timeout 320s;
fastcgi_read_timeout 1600s;
fastcgi_buffer_size 128k;
fastcgi_buffers 512 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors off;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/apps/coolapp$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
# nginx will buffer objects to disk that are too large for the buffers above
fastcgi_temp_path /tmpfs/nginx/tmp 1 2;
#fastcgi_keep_conn on; # NGINX 1.1.14
expires off; ## Do not cache dynamic content
Here are some errors messages I pulled from error.log
2014/02/28 11:10:17 [error] 9215#0: *933 connect() failed (111: Connection refused) while connecting to upstream, ................. client: x.x.x.x, server: mysite.com, request: "GET /coolapp/test.php HTTP/1.1", upstream: "fastcgi://[::1]:9000", host: "www.mysite.com"
2014/02/28 11:10:17 [error] 9215#0: *933 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: x.x.x.x, server: mysite.com, request: "GET /coolapp/test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.mysite.com"
2014/02/28 11:11:59 [error] 9220#0: *1193 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: x.x.x.x, server: mysite.com, request: "GET /coolapp/test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.mysite.com"
Does anyone see what I'm doing wrong?
This appears to have been fixed in a newer version. As long as SCRIPT_FILENAME is set to $request_filename, it should work as expected. (This differs from previous versions, where $request_filename wouldn't work in all cases.) Additionally, you need to omit any try_files directive in the inner location block. Re-evaluating $uri appears to throw off $request_filename.
Ok, second read after coffee. Get the SCRIPT_FILENAME out of the included fastcgi configuration and set it in both location blocks. If this doesn't fix things then in the coolapp location hardcode the doc root path and see if that fixes things.