Where did the cyclical redirect?

When you try to open the page everything works normally. Except for some files.
Part of the statics gives with redirecting.

For example, there is a picture
am49.ru/uploads/2016/05/am49.ru.f941d38af67781d48b...

When you try to show it on the page makes a few redirects. In the end, the image url turns out like this
94.247.56.247/94.247.56.247/94.247.56.247/94.247.5...

Part of pictures, with the same way, giving fine without a redirect
am49.ru/uploads/2016/05/am49.ru.f941d38af67781d48b...

From the name/mask of a file name bug does not depend on the same problem with
am49.ru/talk/style_images/ip.boardpr/logo4.jpg

Different images may have different number of redirects somewhere 2, somewhere abuts the limit of the browser.

Config for tests left like this, minimum. Redirect is not lost.
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

events {
 worker_connections 1024;
}

http {
 include /etc/nginx/mime.types; 
 index index.html index.htm index.php;
 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"'
'$upstream_cache_status';

 access_log /var/log/nginx/access.log main;

 sendfile on;
 timeout 300s;

 types_hash_max_size 2048;

 server_tokens off;

 server {
 listen 80 default_server;
 server_name am49.ru;

 location / {

 "proxy_redirect" off;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Accept-Encoding "";
 client_max_body_size 328M;
 client_body_buffer_size 328k;
 proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 90;
 proxy_buffers 32 4k;

 proxy_set_header Host 'am49.ru';
 proxy_pass http://127.0.0.1:8080;
}

 location ~* \.(gif|jpg|jpeg|png|bmp|mp4|flv)$ {
 root /home/auto.magadan.EN/html/;

 access_log off;
 expires max;
 add_header Last-Modified "";

 try_files $uri $uri/ =404;
}
}
}


The mime file.standard types, the one with the installation of nginx did. Not changed.

nginx version: nginx/1.6.3

With nginx -V watched as the config is the only file. And edit it. Other not connect.

In what direction to dig?
July 9th 19 at 10:42
3 answers
July 9th 19 at 10:44
Solution
first, nginx uses channeling without regexps, most likely you fulfills the first rule.
how to check:
vklchit debug logging and see the path
how to fix:
to include a second location in the first
>most likely you have fulfills the first rule.
in access log of Apache static at all. It turns out, the second location is triggered, and gives it to nginx.

>to include a second location in the first
tried. it did not help.

>vklchit debug logging and see the path
log included - Zoie.OReilly43 commented on July 9th 19 at 10:47
: let's log of the initial request until the redirect - giovanna.DuBuque commented on July 9th 19 at 10:50
: I don't see in the logs the query these resources - Zoie.OReilly43 commented on July 9th 19 at 10:53
: so nginx is not guilty. - giovanna.DuBuque commented on July 9th 19 at 10:56
: and in the Apache logs, nothing there.
the headers of the images obtained after the redirect, written in nginx

https://www.dropbox.com/s/cuk4j6iqr2u5cc6/%D0%A1%D... - Zoie.OReilly43 commented on July 9th 19 at 10:59
: access_log off;
Show end the config with debug - giovanna.DuBuque commented on July 9th 19 at 11:02
: now this is
https://gist.github.com/Dimasmagadan/622830c224cb7...

Leave for minimum of tests is not able to users go. - Zoie.OReilly43 commented on July 9th 19 at 11:05
in the /var/log/nginx/debug-error.log should get any request came to this nginx. There should be a request for your pictures. - giovanna.DuBuque commented on July 9th 19 at 11:08
: why do you call the picture on the ip? - giovanna.DuBuque commented on July 9th 19 at 11:11
:
>have to get any request
understand why don't see, trying to understand
put a debug to your ip, look at all the logs

>why do you call the picture on the ip?
for pictures turn your domain name
so
am49.ru/uploads/2016/05/am49.ru.f941d38af67781d48b...
but somehow throws in the ip domain.

where does this redirect and want to find out - Zoie.OReilly43 commented on July 9th 19 at 11:14
: nginx.org/ru/docs/http/request_processing.html Priorat location that you did not write that nginx uses the first law without regexps. - Giles_Funk63 commented on July 9th 19 at 11:17
tried and here are the location to add

location / {}
location /uploads {} - Zoie.OReilly43 commented on July 9th 19 at 11:20
: added now here is

location /uploads/ {
 add_header Loc-Test "uploads";
...
}

location ~* \.(gif|jpg|jpeg|png|bmp|mp4|flv)$ {
 add_header Loc-Test "regexp";
...
}


that is, did two location which should work on statics
one with the regular season, the other without.
checked first with the regular season - Zoie.OReilly43 commented on July 9th 19 at 11:23
I'm sorry, of course meant a complete coincidence, for example:
location ~* .gif$ {}
location /upload/a.gif {}

Will fulfill the second rule, despite the fact that it is late.

describe why it works as you write. - giovanna.DuBuque commented on July 9th 19 at 11:26
the problem was on the side of host not correctly configured something on their network.
now fixed.
thanks for the tips. - Zoie.OReilly43 commented on July 9th 19 at 11:29
July 9th 19 at 10:46
Solution
this is the full configuration? what have you implemented 404 error, there is a named location?
This is what was used for the tests.
For tests I tried and so
try_files $uri $uri/;

On a live website is now more complete config.

Under a separate 404 location no.
The files on this path on the server is, 404я error on them, in theory, should not appear? - Zoie.OReilly43 commented on July 9th 19 at 10:49
put the full configuration. - giovanna.DuBuque commented on July 9th 19 at 10:52
:
now here's a
https://gist.github.com/Dimasmagadan/622830c224cb7... - Zoie.OReilly43 commented on July 9th 19 at 10:55
the problem was on the side of host not correctly configured something on their network.
now fixed.
thanks for the tips. - giovanna.DuBuque commented on July 9th 19 at 10:58
July 9th 19 at 10:48
Solution
The problem was on the side of host not correctly configured something on their network. Was able to repeat the same bug was and on the other site on their site.

Now fixed.
Thank you all for the advice.

Find more questions by tags ApacheNginx