error on reverse proxy

[gpopesc]

Hello

I am running the latest YoutubeDL-Material on docker version in my synology NAS and I really like it. I can run it directly from my network without any issues using http connection on certain port.

If I try to setup on reverse proxy, on secure connection (using cloudflare ssl), to be accesible from internet, I got the error from following file below: ytdl-error.txt

I tried to edit the file encrypted.json, in case the app use it, bur I got the same error. Any help is apreciated.

Thank you

[Tzahi12345]

Do you mind sharing your configuration (nginx/apache2) for the reverse proxy? Might help in the debugging process, as something might be configured on that end.

You don't need to use the encrypted.json. It's just a template, and you should only use it if you want encryption without a reverse proxy, which isn't applicable here.

EDIT: Also be sure to check out the reverse-proxy guide if you haven't already.

[gpopesc]

thank you for your quick answer. here it is my configuration for reverse proxy with ytdl. In synology is standardized the configuration and it works for many docker containers

ytdl_reverse_proxy.txt.txt

[Tzahi12345]

Hi, sorry for the late response! Your nginx configuration looks mostly good (just a few extra headers that are being passed, but I doubt that makes an impact).

Can you try using a subpath and seeing if that works? (not as a permanent solution, but more for debugging)

If you're able to edit the nginx config, add these location blocks:

location ~/ytdl(.*)$ {
  rewrite /ytdl/(.*) /  break;
  proxy_pass http://example.com:8998;
}

location /api/ {
  proxy_pass http://example.com:8998;
}

Then try accessing youtubedl.xxxx.com/ytdl/. Let me know if you have any luck fixing this.

[gpopesc]

nginx.zip

I have no big expertise in nginx config file and I am afraid to do something wrong. See attached my configuration and modify it where you consider.

[Tzahi12345]

nginx.zip

I made a tiny modification to the 443 block towards the bottom (it deals with the HTTPS stuff). I added these lines (though maybe localhost should be replaced with your ipv4 address):

location ~/ytdl(.*)$ {
    rewrite /ytdl/(.*) /  break;
    proxy_pass http://localhost:8998;
}

location /api/ {
    proxy_pass http://localhost:8998;
}

Let me know if you can access youtubedl.xxxx.com/ytdl/!

[gpopesc]

I got the same error like before. the file attached.

steps: backup the original file, replace with new one, nginx restarted error.txt tested on https://youtubedl.xxxx.com/ytdl/ and https://youtubedl.xxxx.com

I can privately share with you the real link, I don't know if it helps.

[Tzahi12345]

Sure, email me the link at [email protected], though I'll probably encounter the same error.

Maybe I'm confused on the synology reverse proxy setup, but are the nginx config files auto generated through the reverse proxy screen? Also, on what port is your YoutubeDL-Material container running on, is it 8084?

Just wanna make sure we didn't miss anything silly.

[kzaoaai]

same issue for me. I also use cloudflare. When I turn off CF proxying, the page loads. I, however, lose the SSL and Origin certificates and other CF features.

[kzaoaai]

same issue for me. I also use cloudflare. When I turn off CF proxying, the page loads. I, however, lose the SSL and Origin certificates and other CF features.

I solved my problem. I removed add_header X-Content-Type-Options nosniff; from my nginx configuration, and also turned off the no-sniff header in Cloudflare's HTTP Strict Transport Security (HSTS) settings. It's working for me as a subdomain (ytdl.mydomain.com). Subfolder (mydomain.com/ytdl) still had the same issue, but that's good enough for me.

[Tzahi12345]

I don't quite understand why the reverse-proxy config fails with different setups. Not sure where the common thread is with this (or these) problem(s) as @gpopesc's config did not contain that line.

[AlexanderSch90]

Same here with pfSense. I removed add_header X-Content-Type-Options nosniff and it works

[dovy6]

I'm not sure if this is helpful, but here's a proxy-conf that works with swag (formerly letsencrypt) using nginx. Save this file as youtube-dl.subfolder.conf

## Version 2020/12/23
# Works with this youtube-dl-material Fork: https://github.com/Tzahi12345/YoutubeDL-Material


location /youtube {
    return 301 $scheme://$host/youtube/;
}

location ^~ /youtube/ {
    # enable the next two lines for http auth
    #auth_basic "Restricted";
    #auth_basic_user_file /config/nginx/.htpasswd;

    # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
    #auth_request /auth;
    #error_page 401 =200 /login;

    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app  youtube-dl-material;
    set $upstream_port 17442;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    proxy_redirect  off;
    proxy_set_header Referer '';
    proxy_set_header Host $upstream_app:17442;
    rewrite /youtube(.*) $1 break;
}

location ^~ /youtube/api/ {
     include /config/nginx/proxy.conf;
     resolver 127.0.0.11 valid=30s;
     set $upstream_app youtube-dl-material;
     set $upstream_port 17442;
     set $upstream_proto http;
     proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ^~ /api/ {
     include /config/nginx/proxy.conf;
     resolver 127.0.0.11 valid=30s;
     set $upstream_app youtube-dl-material;
     set $upstream_port 17442;
     set $upstream_proto http;
     proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}

[gpopesc]

I ended up to a simple solution: I created a free account to a DDNS provider (ex: dnsexit.com) and I put that name in reverse proxy configuration and I use it only for youtube dl. It works for port 80, also for 443 (with ignore warning as I didn't create a certificate for this domain). Cloudflare strict security don't work reverse proxy and youtube-dl.

[tigattack]

I've also seen X-Content-Type-Options nosniff break the reverse proxy using NGINX. May be worth noting this in the docs.

[GlassedSilver]

Do the current nightly builds still expose this behavior?

[ofifoto]

They do, yes -- it seems to be because content-type: text/html is missing from the server's response. When the security header (which should usually be enabled) x-content-type-options: nosniff is there the browsers - having no specified content-type header - will refuse to guess and either display it as text (Chrome) or force a download (Safari)

[GlassedSilver]

Disclaimer: I have only recently started getting a bit closer with the code, my current contributions aren't even in JS for the most part and when they are, they are fixes I can commit by doing some educated guessing and spotting issues in code that are more of the logical nature.

That being said, if my CTRL-F skills and a bit of googling don't fail me, we might be looking at this section here:

https://github.com/Tzahi12345/YoutubeDL-Material/blob/8118906b0af328c3870264d4d1f95803f8bbc53c/backend/app.js#L676-L684

That section does work with Content-Type, so maybe that's not the issue here.

Could this StackExchange thread possibly shed some light onto this?

Also, I take it this is something that @Tzahi12345 might be able to pinpoint better now since he last checked out the problem. (not sure though, I can only guess)

[ofifoto]

Hmmm.. here's what I see querying the app for its headers directly (vs via a reverse proxy):

$ curl -s -D - -o /dev/null http://127.0.0.1:8998
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Origin: https://<url removed>
Date: Sat, 14 May 2022 05:47:55 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

and querying a JS file directly:

$ curl -s -D - -o /dev/null http://127.0.0.1:8998/runtime.36bbc614a219a0b0.js
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Origin: https://<url removed>
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Sun, 08 May 2022 06:18:46 GMT
ETag: W/"b4a-180a2520570"
Content-Type: application/javascript; charset=UTF-8
Content-Length: 2890
Vary: Accept-Encoding
Date: Sat, 14 May 2022 05:48:48 GMT
Connection: keep-alive
Keep-Alive: timeout=5

the index seems to be missing that Content-Type saying it's a text/html response

[adambeutler]

They do, yes -- it seems to be because content-type: text/html is missing from the server's response. When the security header (which should usually be enabled) x-content-type-options: nosniff is there the browsers - having no specified content-type header - will refuse to guess and either display it as text (Chrome) or force a download (Safari)

This is the same issue I am having while using cloudflair ZeroTrust. I can get to the page but it loads as just the html code instead of loading the page correctly. Is there a way to fix this?