SickRage Info:
Branch: master
Commit: 570cd207fe00798fb2182b0a90af16c1d936ea83
Version: 2016.07.10-1
Database Version: 44.0
Python Version:
2.7.10 (default, Oct 14 2015, 16:09:02) [GCC 5.2.1 20151010]
SSL Version:
OpenSSL 1.0.2d 9 Jul 2015
OS:
Linux-4.2.0-42-generic-x86_64-with-Ubuntu-15.10-wily
Hello
I have an issue with sickrage and nginx in reverse proxy with
"invalid paramaters" when I click on a show
Every other services (couchpotato, sabnznd) are working well
Here is the proxy conf:
client_max_body_size 10m;
client_body_buffer_size 512k;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;
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_set_header X-Forwarded-Proto https;
And the reverse conf:
server {
listen 443 ssl;
server_name localhost 192.168.0.28 grabbing2.xxx.com;
include /etc/nginx/conf.d/ssl.conf;
access_log /var/log/nginx/grabbing-access.log;
error_log /var/log/nginx/grabbing-error.log;
location /sickrage/ {
include /etc/nginx/global.d/proxy.conf;
proxy_pass https://192.168.0.28:8081/sickrage/;
proxy_set_header Host 127.0.0.1:8081;
}
location /nginx_status {
stub_status on;
access_log off;
}
}
Thanks for help
Thanks for the issue report! Before a real human comes by, please make sure your report has all the below criteria checked
Please make sure you also read how to create an issue and followed all of the steps.
The title should describe your issue. Having "SR not working" or "I get this bug" for 100 issues, isn't really helpful. We will close issues if there isn't enough information.
Sometimes the devs may seem like grunts and respond with short answers. This isn't (always) because the dev hates you, but because he's on mobile or busy fixing bugs. If something isn't clear, please let us know, and this bot may get updated to automatically answer you.
Thanks!
This configuration actually is working for me. Can you try it ?
location /sickrage {
proxy_pass http://127.0.0.1:8081;
proxy_read_timeout 180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
I got bad gateway error
if I tweak
location sickrage/
and proxypass 8081/sickrage/
it works,with ... invalid parameters
does it work if you connect directly to https://192.168.0.28:8081/sickrage/ ?
yes flawlessly
Maybe it has something to do with the trailing slash / or possibly sub-paths? You could try adding a .* after the location path. The following works for me:
location ~ /sickrage.* {
proxy_pass http://127.0.0.1:8081;
proxy_read_timeout 180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Thanks for your help
with this I get 404 !
doesn't work at all
This is very likely a configuration issue. Here is what I have configured that works:
http://192.168.0.28:8081/sickragelocation ~ /sickrage.* {
proxy_pass http://127.0.0.1:8081;
proxy_read_timeout 180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
_Note: The request is being passed to http with no additional url appended afterwards because the original request that is passed along will already include /sickrage. This is why we configured web_root in sickrage._
nginx -t && service nginx restarthttps://192.168.0.28/sickrage_Note: If there are problems at this point, you'll need to take a look at the nginx logs to see where the request is being passed to. It will include the url, which if you were to try, will likely fail as well, which will be a clue._
OK
Access with HTTPS and IP is OK ! :)
Access with domaine name (https://sample.com/sickrage) gives me invalid parameters
Thanks for your advises and patience :)
What is really strange is couch, sab etc ... are working flawlessly (with same settings that sickrage)
This sounds suspiciously like some sort of caching issue. Almost like some code being executed in the browser is incompatible or out of date with the server.. If you have any caching controls configured in nginx, I'd remove them for now. If there is any filesystem caching with nginx, remove them. Any reference to sendfile, comment out as well. Restart nginx. And then clear browser cache, try another browser and/or CTRL + F5 and see if the results are any different..
var/cache/nginx destroyed and rebuild
browser cache cleaned
Same behavior only on sickrage of course
:(
BTW !!!!!!
forgot to explain
the invalid parameters emerge only when I click on a show
It could be a missing variable passed to backend. If you enable debug log in SR, is there something in the log when you got missin parameter error.
Same way you could enable nginx loggind to debug, which requestes are performed by nginx in the error condition
debug log for SR ....nothing concerning tornado or something not cleanly send
But in Nginx .... maybe that from grabbing-error.log ?
2016/10/12 10:11:07 [warn] 1879#1879: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/1/00/0000000001 while reading upstream, client: 192.168.0.180, server: 127.0.0.1, request: "GET /sickrage/showPoster/?show=308772&which=fanart HTTP/1.1", upstream: "http://127.0.0.1:8081/sickrage/showPoster/?show=308772&which=fanart", host: "mydomain.com", referrer: "https://mydomain.com/sickrage/home/displayShow?show=308772"
can you try again with this location for nginx ?
location /sickrage
same :/
tried to disable proxy caching?
client_max_body_size 0;
client_body_buffer_size 0;
proxy_buffering off
same
I disabled it in global.d/proxy.conf
cleaned the browser cache before
added proxy_buffering off
SAME
i'm desperate
I've never had a problem with nginx reverse proxying
int config.ini I have web_root=/rage
in my server block I have the following:
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
the location block:
location /rage/ {
proxy_pass http://10.0.0.12:8081/rage/;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/users.htaccess;
}
Obviously you'd need to use your own IP of the server running SickRage, not 10.0.0.12
I don't know if all the proxy_set_header directives are required for SickRage, but other applications need them.
If you're going to use basic auth, you need to make sure it only goes over an SSL connection.
Got your settings
used the good ip and not 127.0.0.1
still not working
I'm going to make a new VM with ubuntu 16.04 and rebuild everything to test ...
I'm going to make a new VM ubuntu 160
@stanthewizzard you got this figured out? I experience the exact same issue.
What is your configuration for the proxy?
server{
listen 443 ssl;
server_name mydomain 192.168.1.168 127.0.0.1 host;
root /var/www/html;
index index.php index.html index.htm;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;
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_set_header X-Forwarded-Proto https;
proxy_redirect http:// $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 32 4k;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
}
location /sickrage {
proxy_pass http://127.0.0.1:8081;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
All other services are working fine that way. I tried several combinations also with local IP. If I connect directly against that it's fine. Firefox, Chrome... same behavior, Invalid Parameter when opening a show.
(I know there is some redundancy... but I have a shitton of services and happy it's working... at least with this little quirk)
Is this enabled in SR preferences?
Reverse proxy headers
accept the following reverse proxy headers (advanced)...
(X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto)
can you eneble tornado logs and post the result when the error happen
Yes of course.
can you eneble tornado logs and post the result when the error happen?
No sure how to enable debug logging in tornado, the normal debug log shows nothing. Is there a dedicated option for this?
But in the meantime I tried this on a fresh installed windows client with chrome and no configuration at all, and the error is gone. Weird, must be something with an extension or some further config but weird that I have the same issue with FF.
Sorry to bother with something that seems an issue on the client side.
No solution for me ... and no issue with ... ;)
@miigotu @sharkykh maybe we need to add some better docs for using Sickrage properly with reverse proxies? If there are docs for this maybe they need to be put in a better place so users can find them.
Just to help maybe another person with the same issue... for me it was the LastPass Chrome & FF Extension which 'created' my issue. Without it is fine...
Also the proxy documentation situation is fine in my book, you'll find plenty of resources.
confirmed. Lastpass in chrome, the bug is "invalid paramaters" is there.
Lastpass remove, no more bug.
Very very strange !!!
Thanks mason-xx
If someone can give me a full nginx config along with the exact error that's shown I should be able to track down what's causing this.
My config is rather chaotic, guess it would make more sense if someone could provide a cleaner example. If I find the time I will setup a clean VM, if nobody is faster.
This is a bug with the lastpass extension then, nothing we can do about that. Either need to know what the invalid parameter was or nothing I can even suggest.
@miigotu that's why I wanted to look into it. I have a feeling it's changing the referrer header or something.