Open unixfox opened 2 years ago
NGINX config for tcp pass-through with TLS decryption and encryption:
worker_processes auto;
worker_rlimit_nofile 100000;
events {
# determines how much clients will be served per worker
# max clients = worker_connections * worker_processes
# max clients is also limited by the number of socket connections available on the system (~64k)
worker_connections 4000;
# optimized to serve many clients with each thread, essential for linux -- for testing environment
use epoll;
# accept as many connections as possible, may flood worker connections if set too low -- for testing environment
multi_accept on;
}
stream {
map $ssl_server_name $newhost {
"~^(.*).example.com" $1.googlevideo.com;
default $ssl_server_name;
}
server {
listen 443 ssl;
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256;
ssl_certificate /root/nginx-selfsigned.crt;
ssl_certificate_key /root/nginx-selfsigned.key;
proxy_connect_timeout 1s;
proxy_timeout 3s;
resolver 1.1.1.1;
proxy_pass $newhost:443;
proxy_ssl on;
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256;
}
}
http {
map $host $newhost {
"~^(.*).example.com" $1.googlevideo.com;
default $host;
}
server {
listen 8443 ssl;
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256;
ssl_certificate /root/nginx-selfsigned.crt;
ssl_certificate_key /root/nginx-selfsigned.key;
resolver 1.1.1.1;
location / {
proxy_pass https://$newhost:443;
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256;
}
}
}
Test on oracle cloud ARM first.
rr3---sn-5hne6n6e.c.eu1.example.com -> rr2---sn-a0jpm-a0md.c.eu1.example.com
works for sub sub domains
Have a central backend for redirection to other servers and handling rate limits.
This backend would be on fly.io with anycast and proxy the requests directly to the specified servers so that less request need to be done.
The backend could also be the one doing the requests to YouTube servers, reducing the load to the proxy server. Need to investigate how to do the requests: through SSH proxy? Or maybe just a proxy handled in nginx to innertube api This traffic could be encrypted by wireguard: https://fly.io/docs/reference/private-networking/
The cache would be kept in redis of fly.io: https://fly.io/docs/reference/redis/#create-and-manage-an-upstash-redis-database.
proxy in youtube library: LuanRT/\YouTube.js\/pull\/62 and proxy server: https://github.com/3proxy/3proxy
Have proxy servers on stardust scaleway servers: https://www.scaleway.com/fr/stardust-instances/ or cheap VPS with unlimited BW (or +80TB of allowance). Some servers will be in IPv6 only.
These servers will have http3-ytproxy as a direct entrypoint with certmagic for the TLS certificate generation and they will redirect the requests for the latest_version and dash manifest paths to:
The http3-ytproxy program will limit the flow per connection using one of these methods:
Each server will be rotated using a redirect in NGINX.
Need to investigate too the ability the swap googlevideo.com to
c.docs.google.com
orc.drive.google.com
or any other domain likec.example.com
.Interesting links:
Replicate the requests done by Invidious for latest_version and dash manifest: https://github.com/LuanRT/YouTube.js#streaming