The Stack Overflow podcast is back! Listen to an interview with our new CEO.

New answers tagged

0

Have you tried the nginx rewrite module? Something like this should do the trick server { listen <ip.address>:<port> server_name <domain>.biz location / { rewrite ^https://<domain>.biz/(.*)$ https://<domain>.com/$1 } }


1

I think you are missing an essential piece of your setup. While you show the internal configuration of the server which has different internal IP addresses for the two servers and you explain the external configuration where both domains have the same IP address, you don't explain how the mapping from the external IP address to the correct internal IP ...


0

I found official documentation. It refers to variables in general, but the sentiment is clear: hardcode if possible. Variables should not be used as template macros. Variables are evaluated in the run-time during the processing of each request, so they are rather costly compared to plain static configuration. Using variables to store static strings is ...


0

You can also combine Alexey Ten's answer with the geo module as mentioned in Nginx - How to redirect users with certain IP to special page This makes it easier to match multiple IP addresses due to CIDR notation and ranges support. E.g. geo $geo_host { default 0; 127.0.0.1/16 1; 1.2.3.4 1; } server { ... # Skipping details ...


0

Strip prefix from $fastcgi_script_name: fastcgi_split_path_info ^\/phpmyadmin\/(.+\.php)(.*)$; Then use it: fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;


-1

This question has been answered elsewhere. There seem to be 2 strategies: Using the nginx geo module. Nginx - How to redirect users with certain IP to special page Using a variable for the root dir. Nginx document root based on client ip?


1

There are many ways. Some have been outlined in some answers. If you use the ngx_http_js_module, there is also a way to do that with JS: ## /etc/nginx/fetch_env.js function fetch_upstream_host(r) { return process.env.UPSTREAM_HOST; } function fetch_upstream_port(r) { return process.env.UPSTREAM_PORT; } and ## /etc/nginx/nginx.conf load_module ...


1

Only one location block will be selected by nginx, with matching regular expression locations preferred over static prefixes. Thus, when a static asset is being served, the location ~* <etc> block is being used, which doesn't include the gzip_static on setting. Copy that into the static assets block and it'll all Just Work again.


-1

Yes, you create as many servers as required. I have each site in a different file, and each site has 2-3 servers to account for https forwarding and such. I include them all from my nginx.conf like this include /etc/nginx/enabled-sites/*; I have a tutorial here which has some downloadable Nginx files which should help you. I've included an example below as ...


0

If your IP starts with anything from 172.16.x.x to 172.31.x.x, that's not a public IP. That's a private IP that won't route past your firewall. You need the WAN IP address of your router.


0

The problem is these directives are actually duplicated. One is in main configuration file nginx.conf and the other in default. You need to change one or the other so it stops complaining. It must be unique to a given server context.


0

It sounds like you want nginx to redirect to another URL if it determines the domain to be "down", however this configuration would be serving requests based on the initial domain name being up (that's now the request reached nginx). You could investigate HTTP Load Balancing which also supports Health Checks for upstream servers: monitor transactions as ...


1

Seems like nginx couldn't resolve the someserver.vps address (we had some dns problems a few days ago) and, as you said nginx was treating the syslog as a literal filename, and created on the daemons home directory. We were receiving logs on the remote syslog server thanks to the rsyslog configuration. And that's what was confusing me. Thank you very much ...


0

From the documentation: Logging to syslog is available since version 1.7.1. If your version is older, nginx would treat the syslog directives as a literal filename. In that case this line: access_log syslog:server=someserver.vps:10514,tag=nginxaccess vhosts; configures nginx to write an access log to a file with the name syslog:server=someserver.vps:...


1

Then you'll probably want to insert a virtualhost in your nginx configuration. Something like: server { listen 80; server_name sub.example.com; rewrite ^(.*)$ $scheme://example.com/sub/$1 redirect; }


1

Turns out, the --with-compat option was causing the issue. I added it because the guide on nginx.com said so, but after removing it and compiling one more time, nginx -t tells me that the config is good.


1

I could find the answers myself. This will help someone in future. For Q1: location / { if ($arg_test ~* yes) { return 301 https://sub2.domain.com/v2/page/embed?new=1; } } For Q2: location / { if ($arg_test ~* yes) { rewrite ^(.*)$ https://sub2.domain.com$1; } }


0

If that is a regular expression, you are using the wrong syntax for the location directive. See this document for details. You only need to give proxy_pass a URI part, if the URI is changed before passing upstream. See this document for details. For example: location ~ ^/api/v1/users/[0-9a-z]+/store { proxy_pass https://bar.foo; ... }


0

Just in case anyone comes here with Apache using mod_wsgi, this can be solved by adding the lang and locale options to the WSGIDaemonProcess line in your site's config file. Should normally be set to en_US.UTF-8 according to the docs: https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html Like so: lang=en_US.UTF-8 ...


0

This is an old post, but I thought I would share the following for anyone else who finds this question. Another option would be to use CloudFront. Requests will then come from a range of IP addresses and potentially mitigate this problem. Let's say you have yourstore.com, and you have blog.yourstore.com. You could set up a CloudFront distribution like so: ...


1

Put your sock file in /var/run and when your sock file is created check for which user and group does it belong to. For your case user should be 'app'


1

You can use: server { # Permanent redirect to an individual page rewrite ^/oldpage$ newpage permanent; }


0

Those fastcgi_index and the final location directives indeed have no effect. The index directive can be shortened as well. The root directive inside the first location doesn't change anything either Besides, on fresh Nginx installations there is a fastcgi-php.conf file which sets the SCRIPT_FILENAME parameter as well, so these days this is perfectly enough: ...


1

If you are using Amazon Linux 2, following will work mostly . sudo yum install pcre-devel sudo yum install zlib-devel sudo yum install openssl-devel.x86_64 mkdir nginx-build cd nginx-build wget http://nginx.org/download/nginx-1.16.1.tar.gz wget https://github.com/leev/ngx_http_geoip2_module/archive/3.2.tar.gz wget https://github.com/maxmind/...


1

This is actually an expected behavior with this config. So, what you are doing, is stripping the URL and then passing it to try_files. But there is nothing in try_files to handle files without an extension. To do that, modify it like this try_files $last_path_component $last_path_component.json $last_path_component.json =404; This will allow you to serve ....


0

You could simplify the configuration by placing all of the static content under a common URI prefix (e.g. /maintenance/...). For example: location / { if ($remote_addr != '1.2.3.4') { rewrite ^ /maintenance/ last; } ... proxy_pass ...; } location /maintenance/ { root /path/to/root; index index.html; } The maintenance page ...


0

Slight change to vog's answer to include a default handler for other methods like OPTIONS, PUT, etc. upstream webdav_default { server example.com; } upstream webdav_upload { server example.com:8081; } upstream webdav_download { server example.com:8082; } server { map ...


1

It's not a command, it's a directive that should be put in your nginx.conf. As per documentation: in Nginx you need to add several lines to your nginx.conf. In every server block where PageSpeed is enabled add: pagespeed on; It's a snippet from the configuration file. The same goes for other directives such as pagespeed rewrite_images on


1

Every ssl virtualhost must define key/cert. So in your case if you wrote "listen ... ssl", you have to write ssl_certificate lines. It is not important, if that key/cert pair will be used for anything else. You can have aliases. I.e. if your key/cert pair in /etc/letsencrypt/live/example.com is valid for both example.com and www.example.com (i.e. that is ...


0

The cause of the issue is this, I already had Apache web server installed and actively listening on port 80 on my local machine. Apache and Nginx are the two major open-source high-performance web servers capable of handling diverse workloads to satisfy the needs of modern web demands. However, Apache serves primarily as a HTTP server whereas Nginx is a ...


2

The specification of a location in the first example indicates that you might have locations or paths that should not be redirected to the HTTPS listener, for some reason. The second example should take all traffic to the given hostname and redirect it.


1

try_files is used to refer to physical files on the filesystem. With your configuration, when requesting /login/?param1=value1, nginx tries to find file /var/www/app_one/dist/login/param1=value1. Depending on the actual contents of param1 and value1, nginx might respond with 400 Bad request, because some characters are not allowed when accessing files.


0

My bet is that you should fix these lines: fastcgi_param SCRIPT_FILENAME **$request_filename**; rewrite /api/(.*)$ **/api**/index.php?/$1 last; Faced a similar problem and found answers here: https://serversforhackers.com/c/nginx-php-in-subdirectory


0

As you are already using Apache as your "frontend" (reverse) proxy, just change the listening port of your nginx and tell apache to fetch content there. This is done by changing the listen parameter in your nginx config, for example to 8443. Debian based: /etc/nginx/sites-enabled/default Most others: /etc/nginx/nginx.conf Then just add another vhost or ...


1

This is quite tricky because the $status variable is empty when declaring the limit_req_zone. The $status is only known after nginx has processed the request. For example after a proxy_pass directive. The closest I could get to achieve rate limiting by status is doing the following: ... ... ... limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s; ... ...


0

Set the base URL properly in the Presta Shop configuration. From the documentation: To add a URL to a shop, select the shop in the "Multistore tree" selector, and then click on the "Add new URL" button. Setting the Main URL option seems like what you want to do.


0

In my point of View, you double your config, Port 80 Section; You are listening on 80 for (www.)domain.com Port 443 First, you are listening on 443 for www.domain.com -- Here you are using domain.com have to be used Port 443 Second, you are listening on 443 for domain.com -- Here you have your load ---- but WHY? In my Mind you complex your config with no ...


0

why not just deny all server { listen 80 default_server; server_name _; location / { deny all; } }


1

According to the comments below your question, the initial problem was that your code captured the file extension of a requested image, and searched for a file which file name was made up of the file extension and the trailing webp suffix, for example jpg.webp. -- Regarding how to serve either image.webp or image.jpg etc: Populate the variables which are ...


0

server { listen 80; listen [::]:80; server_name experiment.local; location /404.html { proxy_pass https://minio/bucket/404.html; } location / { proxy_pass https://minio/bucket/; proxy_intercept_errors on; error_page 404 = /404.html; } } Apparently ordering matters somewhat.


0

All the documentation is here Answers: No, the cache manager is responsible for that The special “cache manager” process monitors the maximum cache size set by the max_size parameter. When this size is exceeded, it removes the least recently used data. The data is removed in iterations configured by manager_files, manager_threshold, and manager_sleep ...


0

Side note here In the situation where your're developing using Laravel, in the config/app.php file you can specify timezone only of that project.


3

In your config first server block is the default_server which will be used for all requests that don't match a more specific server. Rather than return 301 https://www.$host$request_uri; in the default_server don't use the Host header from the request as a parameter to generate the redirect, as that can become all kinds of incorrect things, instead use ...


1

Looks like you have built your binary in another directory then the one installed from the distribution repo. And to which your systemd file is pointing. The best course of action now is to just rebuild the binary using the correct installation directory. Check where is your current nginx binary is which nginx Then run the ./configure script with this ...


0

You could use a variable and some checks that bypass the cache on POST or certain pages. For example: In your server block: # Caching set $skip_cache 0; # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $no_cache 1; } if ($query_string != "") { set $skip_cache 1; } # Don't cache uris ...


0

dumb error in proxy_pass location ~ ^/(admin|_api)(/.*)? { ... proxy_pass http://127.0.0.1:4000/$1$2; }


1

Shared web server or database server will use less resources. Fewer copies in memory and on CPU. Single instance also means it works without needing to manage many containers or VMs. An instance per site gives more flexibility. Each can be updated independently or migrated to different hosts. More work to maintain them all, but that can be automated. This ...


0

proxy_pass http://localhost:9000 works and proxy_pass https://localhost:9000 fails That is expected. Under normal conditions you simply can't run both the HTTP and HTTPS service on the same port. You first need to change the service listening to port 9000 to be HTTPS rather than HTTP before proxy_pass https://localhost:9000 will work, or make the HTTPS ...


0

So basically, mine was a Django project. After resetting my root password, I re-activated my virtual environment and restarted Nginx and Gunicorn. This solved my error. Nginx restart : sudo service nginx restart Gunicorn restart : gunicorn --reload <your-wsgi-folder-name>.wsgi bind 0.0.0.0:8000


2

You are using a wrong flag. From the documentation -c filename Specify which configuration file NGINX should use instead of the default So when you run nginx -t -c /etc/nginx/sites-available/3.conf You tell the server to use 3.conf instead of the main configuration. Which of course will give error, as the server block needs to be enclosed. And the ...


Top 50 recent answers are included