Unable to locate root directory of a web app in NGINX? - nginx

I'm struggling with a NGINX based web app , i need to find its root directory that's being served. Its a subdomain and a simple nano /etc/nginx/sites-available/app.refridge.com it has the following contents.
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# http://wiki.nginx.org/Pitfalls
# http://wiki.nginx.org/QuickStart
# http://wiki.nginx.org/Configuration
#
# Generally, you will want to move this file somewhere, and start with a clean
# file but keep this around for reference. Or just disable in sites-enabled.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen *:80;
server_name app.refridge.com;
location / {
rewrite ^ https://$server_name$request_uri? permanent;
}
}
server {
listen *:443 ssl;
server_name app.refridge.com;
access_log /var/log/nginx/app.refridge.com-access.log;
error_log /var/log/nginx/app.refridge.com-error.log;
# SSL configuration
ssl_certificate /etc/nginx/ssl/STAR_refridge_com-bundle.crt;
ssl_certificate_key /etc/nginx/ssl/star_refridge_com.key;
# listen 443 ssl default_server;
There's no root defined even for port 80 and 443 but still the website loads. I mean is there anything i'm missing i need to find the files and do a backup thats why.
Any help would be appreciated.
P.S it's a DigitalOcean droplet.
**UPDATE: ** I think there a reverse proxy setup
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header X-Forwarded-For $remote_addr;
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404; }
Assuming 3000 port so this is a node.js application but still there should be files which i can access and do a backup.
Thanks

Related

failed to dial to (wss://<ip>/subf1/40234): 502 Bad Gateway > websocket: bad handshake

OK, this 502 error is from something different than the other related articles here.
first i managed to setup a v2ray system using ubuntu 22.
I have a domain and a cloudflare account to set DNS for my domain and a 'sub' subdomain connected to my server ip, all set as it should be.
equipped with SSL cert & key using certbot on linux and works ok, website comes up with https just fine.
dns proxy and websocket check are both enable in CF(CloudFlare).
also im using reverse DNS like the famous tutorials saying, so i've edited the /etc/nginx/sites-available/sub.domain.com to become like this:
server {
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name sub.domain.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
location /subf1 {
if ($http_upgrade != "websocket") {
return 404;
}
location ~ /subf1/\d\d\d\d\d$ {
if ($request_uri ~* "([^/]*$)" ) {
set $port $1;
}
proxy_redirect off;
proxy_pass http://127.0.0.1:$port/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
return 404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem; # mana>
ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem; # ma>
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = sub.domain.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name sub.domain.com;
return 404; # managed by Certbot
}
also, have the x-ui v2ray panel installed and everything is setup just right here is a sample vless connection which i used to create normally and worked fine till yesterday:
the 9988 port is defined from x-ui v2ray management panel on the server.
everything was fine until i removed the x-ui panel and installed another version.
since then i cannot make the connections work, no matter what the v2ray client gives this series of errors:
app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: failed to find an available destination > common/retry: [transport/internet/websocket: failed to dial WebSocket > transport/internet/websocket: failed to dial to (wss://<ip>/subf1/40234): 502 Bad Gateway > websocket: bad handshake] > common/retry: all retry attempts failed
proxy/http: failed to read response from 149.xx.xx.xx:80 > io: read/write on closed pipe
some things i did to resolve this are:
restarting nginx
rebooting the server
re-installing the x-ui panel (various versions)
rebuilding the server
changing the subdomain
changing the sub domain + changing the server and gettin a different ip
and SSL is being set just fine with CF SSL selected at Full.
any kind of help and suggestion is so appreciated.

Reverse proxy a URI to a Vagrant box

I have a Wordpress Vagrant box that I access through the URL localhost:9001 (forwarded port.).
I am currently trying to make it accessible through the URL "molecare.dev".
I have created the line in the hosts file that catches that URL and points it to my localhost (this is working because I can see the nGinx splash page) but I am having trouble catching this URL in the server block and proxy_pass'ing this to the URL(localhost:9001).
Here is my /etc/nginx/sites-available/default file`server_name molecare.dev;
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name localhost;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
I have written the following code which I think should do it but I don't know where to place it and if it is correct?
server {
listen 80;
server_name molecare.dev;
location / {
proxy_pass localhost:9001;
}
}
Can anyone see if this is correct and if so where I put this?
Thanks!
In the folder /etc/nginx/sites-available/ create a config file for your site, say 'molecare.dev.conf'.
Modify the block you wrote to the following and put that in the new file and save it:
server {
listen 80;
server_name molecare.dev;
location / {
proxy_pass http://127.0.0.1:9001;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Then create a symlink:
ln -s /etc/nginx/sites-available/molecare.dev.conf /etc/nginx/sites-enabled/molecare.dev.conf
Reload the nginx configuration:
service nginx reload

nginx runs an subdomain to a new app with an existing website

My server already has an RoR app running on Nginx at port 80 , now I want to set the Gitlab in the same server,
Now, I have to access the Gitlab by myserver:1987/
If I want to a access the Gitlab by myserver/gitlab
How to achieve it ?
nginx.conf
http{
include /opt/nginx/sites-enabled/*;
}
...
server {
listen 80;
server_name localhost;
passenger_enabled on;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
index index.html index.htm;
root /home/poc/projects/zeus/public;
passenger_enabled on;
}
sites-enabled/gitlab.conf
# GITLAB
# Maintainer: #randx
# CHUNKED TRANSFER
# It is a known issue that Git-over-HTTP requires chunked transfer encoding [0] which is not
# supported by Nginx < 1.3.9 [1]. As a result, pushing a large object with Git (i.e. a single large file)
# can lead to a 411 error. In theory you can get around this by tweaking this configuration file and either
# - installing an old version of Nginx with the chunkin module [2] compiled in, or
# - using a newer version of Nginx.
#
# At the time of writing we do not know if either of these theoretical solutions works. As a workaround
# users can use Git over SSH to push large files.
#
# [0] https://git.kernel.org/cgit/git/git.git/tree/Documentation/technical/http-protocol.txt#n99
# [1] https://github.com/agentzh/chunkin-nginx-module#status
# [2] https://github.com/agentzh/chunkin-nginx-module
upstream gitlab {
server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}
server {
listen *:1987; # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name dqa-test; # e.g., server_name source.example.com;
server_tokens off; # don't show the version number, a security best practice
root /home/git/gitlab/public;
# Increase this if you want to upload large attachments
# Or if you want to accept large git objects over http
client_max_body_size 5m;
# individual nginx logs for this gitlab vhost
access_log /opt/nginx/logs/gitlab_access.log;
error_log /opt/nginx/logs/gitlab_error.log;
location / {
# serve static files from defined root folder;.
# #gitlab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html #gitlab;
}
# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location #gitlab {
proxy_read_timeout 300; # Some requests take more than 30 seconds.
proxy_connect_timeout 300; # Some requests take more than 30 seconds.
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://gitlab;
}
error_page 502 /502.html;
}

Why is Nginx routing all traffic to one subdomain?

I am new to nginx. I am trying to install GitLabs alongside an existing php project which is currently being served by Apache on port 80. My plan is to get them both working side by side on port 90 and then turn off Apache, switching both projects to Nginx on port 80.
Okay. The problem is that both subdomains are being captured by the server for my php project which should only be served to requests for db.mydomain.com. For the php project I have a file called: ccdb symlinked into /etc/nginx/sites-enabled. It contains:
server {
server_name db.mydomain.com;
listen 90; ## listen for ipv4; this line is default and implied
#listen [::]:80 default ipv6only=on; ## listen for ipv6
root /var/www/ccdb;
index index.html index.htm index.php;
}
However, for some reason, traffic to git.mydomain.com is being serverd from /var/www/ccdb even though I have another file symlinked alongside that one called gitlab with this content:
# GITLAB
# Maintainer: #randx
# App Version: 5.0
upstream gitlab {
server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}
server {
listen 90; # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name git.mydomain.com; # e.g., server_name source.example.com;
server_tokens off; # don't show the version number, a security best practice
root /home/git/gitlab/public;
# individual nginx logs for this gitlab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;
location / {
# serve static files from defined root folder;.
# #gitlab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html #gitlab;
}
# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location #gitlab {
proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://gitlab;
}
}
NOTE: I am accessing the two domains from an OSX machine on the same local network which has entries in it's /etc/hosts file like so:
192.168.1.100 db.mydomain.com
192.168.1.100 git.mydomain.com
Try to use:
server_name git.mydomain.com:90;
... and:
server_name db.mydomain.com:90;

Gitlab clone over http fails to authenticate from external network

I have Gitlab 5.2 + Nginx installed on a local machine in my university. Clone over http works for machines that are within the internal network, but trying to clone from a machine on an external network results in an "fatal: Authentication failed" message, even though the exact same credentials are supplied. (I use the same credentials as the ones I use to log in to Gitlab via the web interface)
The Gitlab web interface is accessible from external networks. It is only the clone over http that fails (clone over ssh is not possible because port 22 is blocked)
Here are some lines from the relevant configuration files:
from config/gitlab.yml
host: mydomain
port: 80
https: false
Here are the relevant lines from the ngnix config file
server {
listen *:80 default_server; # In most cases *:80 is a good idea
server_name mydomain; # e.g., server_name source.example.com;
root /home/git/gitlab/public;
# individual nginx logs for this gitlab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;
location / {
# serve static files from defined root folder;.
# #gitlab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html #gitlab;
}
# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location #gitlab {
proxy_read_timeout 2000; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_connect_timeout 2000; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://gitlab;
}
}
Note: I have added this line to /etc/hosts: 127.0.0.1 mydomain but it doesn't really help. (based on https://github.com/gitlabhq/gitlabhq/issues/3483#issuecomment-15783597)
Any ideas on what the issue might be/how I might debug this?
I believe this is fixed in 5.3, so try updating. See:
https://github.com/gitlabhq/gitlabhq/blob/master/CHANGELOG#L41
https://github.com/gitlabhq/gitlabhq/blob/master/config/gitlab.yml.example#L151

Resources