Tag Info

Hot answers tagged

4

You should also update the wordpress configuration. Without that, wordpress still links the static content to subdirectory. Step taken from Moving your Wordpress from a subfolder to the root directory From the main dashboard, go to Administration -> Settings -> General. Next, look for the WordPress address (URI): and change it from (example.com/wordpress ...


3

The way I see it is as follows: Requests will be served as fast as possible until the zone rate is exceeded. The zone rate is "on average", so if your rate is 1r/s and burst 10 you can have 10 requests in 10 second window. After the zone rate is exceeded: a. Without nodelay, further requests up to burst will be delayed. b. With nodelay, further requests ...


3

Three is no reason for concern in the log entries you posted. The first is a request for an image file that many browsers use as icon when displaying a page from your site or a bookmark. The second request is an attempt to use your server as HTTP proxy. However it looks like your server just ignores the proxy part of that attempt and instead responds as if ...


3

Point of information -- we saw a few requests for this exact same URI (s1.bdstatic.com) come through one of our addresses a few days ago. So i'm reluctant to assume the request is benign, although it could just be someone using that image in a scan for open proxies. 125.64.35.67 1418849297 <internal> GET ...


3

You should use a different server block for each "type" of domain you manage, so that you don't have to use if statements to test the $host variable. # Domains to serve only via HTTPS server { server_name domaintoredirect1.tld domaintoredirect2; listen 80; return 302 https://$host$request_uri; } server { server_name domaintoredirect1.tld ...


2

You need to update the root directive in the configuration, assuming that your WordPress resides under /var/www/html and not /home/git/gitlab/public.


2

Success!! Steps to correct: Used a single site file Added explicit root directive to each location block Order of parsing is important, I've put the location / {} block first added an index directive to location / {} block. Thanks for your help guys! working configuration file: upstream gitlab { server unix:/home/git/gitlab/tmp/sockets/gitlab.socket ...


2

Your server_name definition doesn't match the URL you are using, therefore you are getting the wrong virtual host. Remember, http://www.myserver.com does not work when server_name is mysserver.com.


1

Putting this in the server config block should work: the regexp should match what you need correctly and by stashing the required ID in a variable you can use it later in the rewrite. Assuming that you won't have a 'topic' argument in other parts of the site, there's really no need to scope this in a location - even if you do, you can alter the first part ...


1

You could add the following before any proxy logic and store assets in a directory elsewhere on the machine: location /static { alias /location/for/all/static/assets; } Then, in your app make "/static" the prefix for all static assets.


1

My first thought would be to use a map. map $arg_param $cache_valid_404 { "" 2d; 1 15m; } Then you set: proxy_cache_valid 404 $cache_valid_404;


1

< bot >Convert answer as comment in answer section< /bot > Nginx support multiple root certificates. Just put multiple root CA certificates into a file specified in the ssl_client_certificate directive. Note the docs explicitly say "certificates"(plural). This is a consideration why nginx doesn't support ssl_client_certificate in a directory (as ...


1

< bot >Convert answer as comment in answer section< /bot > I made it work! I removed the ! in the https server directive and removed the ^ from http and https (because request_uri contains the domain as well). server { listen 80; ...... #enforce https if ($request_uri ~ ...


1

I found that stunnel may be a suitable solution to add that layer in between, is it a good solution? I don't aware that nginx have that functionality (i.e. provide client certificate when proxying request to upstream). The stunnel solution works in this case. You can provide certificate per service. Configure it in stunnel.conf [upstream] accept = ...


1

What may be happening is that the Apache 2 init script has higher priority than the Nginx script. You can either change the priorities (but then the lower priority server may not "get its ports"), or just change the init scripts that get run. Change the priority with: update-rc.d nginx defaults update-rc.d apache2 start 30 2 3 4 5 . stop 70 0 1 6 Just ...


1

turns out the issue got fixed by editing php.ini: cgi.fix_pathinfo=0 replaced by cgi.fix_pathinfo=1 then reloading the php-fpm daemon.


1

Parameters, (aka arguments or query strings) are not directly seen as part of the URL for nginx rewrites. Instead, they are saved as variables that can be accessed, tested against, and inserted into the resulting URL. The name they are saved as is $arg_. So, in your first example, you would want to redirect them like so: rewrite ^/page.html$ ...


1

Yes. location ^~ /pma/ { ... } ^~ will prevent nginx to look for regexp locations.



Only top voted, non community-wiki answers of a minimum length are eligible