Originally created by @otakukz17 on GitHub (Mar 23, 2025).
problem description
After correctly configuring the yt-session-generator, the API continues to return a YouTube authentication error for all video requests.
In the Docker logs:
cobalt API ^ω^
version: 10.8.2
commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326
branch: main
remote: imputnet/cobalt
start time: Sun, 23 Mar 2025 16:00:30 GMT
services:
cobalt-api:
image: ghcr.io/imputnet/cobalt:10
init: true
read_only: true
restart: unless-stopped
container_name: cobalt-api
networks:
- cobalt-net
ports:
- 9000:9000/tcp
# if you use a reverse proxy (such as nginx),# uncomment the next line and remove the one above (9000:9000/tcp):# - 127.0.0.1:9000:9000
environment:
# replace https://api.url.example/ with your instance's url# or else tunneling functionality won't work properly
API_URL: "http://129.151.212.247:9000"
API_KEY_URL: "file:///app/keys.json"
API_AUTH_REQUIRED: "1"
YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"# if you want to use cookies for fetching data from services,# uncomment the next line & volumes section# COOKIE_PATH: "/cookies.json"# it's recommended to configure bot protection or api keys if the instance is public,# see /docs/protect-an-instance.md for more info# see /docs/run-an-instance.md for more variables that you can use here
labels:
- com.centurylinklabs.watchtower.scope=cobalt
# uncomment only if you use the COOKIE_PATH variable
volumes:
- ./keys.json:/app/keys.json:ro
# - ./cookies.json:/cookies.json
depends_on:
yt-session-generator:
condition: service_healthy
# watchtower updates the cobalt image automatically
watchtower:
image: ghcr.io/containrrr/watchtower
restart: unless-stopped
command: --cleanup --scope cobalt --interval 900 --include-restarting
volumes:
- /var/run/docker.sock:/var/run/docker.sock
# if needed, use this image for automatically generating poToken & visitor_data
yt-session-generator:
image: ghcr.io/imputnet/yt-session-generator:webserver
init: true
networks:
- cobalt-net
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/token"]
restart: unless-stopped
container_name: yt-session-generator
ports:
- 127.0.0.1:1280:8080
networks:
cobalt-net:
driver: bridge
Originally created by @otakukz17 on GitHub (Mar 23, 2025).
### problem description
After correctly configuring the `yt-session-generator`, the API continues to return a YouTube authentication error for all video requests.
In the Docker logs:
cobalt API ^ω^
~~~~~~
version: 10.8.2
commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326
branch: main
remote: imputnet/cobalt
start time: Sun, 23 Mar 2025 16:00:30 GMT
~~~~~~
url: http://129.151.212.247:9000
port: 9000
[✓] poToken & visitor_data loaded successfully!
[✓] api keys loaded successfully!
### your instance configuration
```shell
services:
cobalt-api:
image: ghcr.io/imputnet/cobalt:10
init: true
read_only: true
restart: unless-stopped
container_name: cobalt-api
networks:
- cobalt-net
ports:
- 9000:9000/tcp
# if you use a reverse proxy (such as nginx),
# uncomment the next line and remove the one above (9000:9000/tcp):
# - 127.0.0.1:9000:9000
environment:
# replace https://api.url.example/ with your instance's url
# or else tunneling functionality won't work properly
API_URL: "http://129.151.212.247:9000"
API_KEY_URL: "file:///app/keys.json"
API_AUTH_REQUIRED: "1"
YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"
# if you want to use cookies for fetching data from services,
# uncomment the next line & volumes section
# COOKIE_PATH: "/cookies.json"
# it's recommended to configure bot protection or api keys if the instance is public,
# see /docs/protect-an-instance.md for more info
# see /docs/run-an-instance.md for more variables that you can use here
labels:
- com.centurylinklabs.watchtower.scope=cobalt
# uncomment only if you use the COOKIE_PATH variable
volumes:
- ./keys.json:/app/keys.json:ro
# - ./cookies.json:/cookies.json
depends_on:
yt-session-generator:
condition: service_healthy
# watchtower updates the cobalt image automatically
watchtower:
image: ghcr.io/containrrr/watchtower
restart: unless-stopped
command: --cleanup --scope cobalt --interval 900 --include-restarting
volumes:
- /var/run/docker.sock:/var/run/docker.sock
# if needed, use this image for automatically generating poToken & visitor_data
yt-session-generator:
image: ghcr.io/imputnet/yt-session-generator:webserver
init: true
networks:
- cobalt-net
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/token"]
restart: unless-stopped
container_name: yt-session-generator
ports:
- 127.0.0.1:1280:8080
networks:
cobalt-net:
driver: bridge
```
I have the same problem too I can't figure out why since it works on my machine without youtube session generator.
@elkofy commented on GitHub (Apr 11, 2025):
I have the same problem too I can't figure out why since it works on my machine without youtube session generator.
After correctly configuring the yt-session-generator, the API continues to return a YouTube authentication error for all video requests. In the Docker logs:
cobalt API ^ω^
version: 10.8.2
commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326
branch: main
remote: imputnet/cobalt
start time: Sun, 23 Mar 2025 16:00:30 GMT
services:
cobalt-api:
image: ghcr.io/imputnet/cobalt:10
init: true
read_only: true
restart: unless-stopped
container_name: cobalt-api
networks:
- cobalt-net
ports:
- 9000:9000/tcp
# if you use a reverse proxy (such as nginx),
# uncomment the next line and remove the one above (9000:9000/tcp):
# - 127.0.0.1:9000:9000
environment:
# replace https://api.url.example/ with your instance's url
# or else tunneling functionality won't work properly
API_URL: "http://129.151.212.247:9000"
API_KEY_URL: "file:///app/keys.json"
API_AUTH_REQUIRED: "1"
YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"
# if you want to use cookies for fetching data from services,
# uncomment the next line & volumes section
# COOKIE_PATH: "/cookies.json"
# it's recommended to configure bot protection or api keys if the instance is public,
# see /docs/protect-an-instance.md for more info
# see /docs/run-an-instance.md for more variables that you can use here
labels:
- com.centurylinklabs.watchtower.scope=cobalt
# uncomment only if you use the COOKIE_PATH variable
volumes:
- ./keys.json:/app/keys.json:ro
# - ./cookies.json:/cookies.json
depends_on:
yt-session-generator:
condition: service_healthy
@FethiAmari commented on GitHub (Apr 16, 2025):
> ### problem description
> After correctly configuring the `yt-session-generator`, the API continues to return a YouTube authentication error for all video requests. In the Docker logs:
>
> cobalt API ^ω^
>
> ```
>
> version: 10.8.2
>
> commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326
>
> branch: main
>
> remote: imputnet/cobalt
>
> start time: Sun, 23 Mar 2025 16:00:30 GMT
> ```
>
> url: http://129.151.212.247:9000
>
> port: 9000
>
> [✓] poToken & visitor_data loaded successfully!
>
> [✓] api keys loaded successfully!
>
> ### your instance configuration
> services:
> cobalt-api:
> image: ghcr.io/imputnet/cobalt:10
> init: true
> read_only: true
> restart: unless-stopped
> container_name: cobalt-api
> networks:
> - cobalt-net
> ports:
> - 9000:9000/tcp
> # if you use a reverse proxy (such as nginx),
> # uncomment the next line and remove the one above (9000:9000/tcp):
> # - 127.0.0.1:9000:9000
> environment:
> # replace https://api.url.example/ with your instance's url
> # or else tunneling functionality won't work properly
> API_URL: "http://129.151.212.247:9000"
> API_KEY_URL: "file:///app/keys.json"
> API_AUTH_REQUIRED: "1"
> YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"
> # if you want to use cookies for fetching data from services,
> # uncomment the next line & volumes section
> # COOKIE_PATH: "/cookies.json"
>
> # it's recommended to configure bot protection or api keys if the instance is public,
> # see /docs/protect-an-instance.md for more info
>
> # see /docs/run-an-instance.md for more variables that you can use here
> labels:
> - com.centurylinklabs.watchtower.scope=cobalt
> # uncomment only if you use the COOKIE_PATH variable
> volumes:
> - ./keys.json:/app/keys.json:ro
> # - ./cookies.json:/cookies.json
> depends_on:
> yt-session-generator:
> condition: service_healthy
>
> # watchtower updates the cobalt image automatically
> watchtower:
> image: ghcr.io/containrrr/watchtower
> restart: unless-stopped
> command: --cleanup --scope cobalt --interval 900 --include-restarting
> volumes:
> - /var/run/docker.sock:/var/run/docker.sock
>
> # if needed, use this image for automatically generating poToken & visitor_data
> yt-session-generator:
> image: ghcr.io/imputnet/yt-session-generator:webserver
> init: true
> networks:
> - cobalt-net
> healthcheck:
> test: ["CMD", "curl", "-f", "http://localhost:8080/token"]
> restart: unless-stopped
> container_name: yt-session-generator
> ports:
> - 127.0.0.1:1280:8080
>
> networks:
> cobalt-net:
> driver: bridge
Hello bro can you help me how can i contact you
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home.
You need a residential IP proxy to make this work
@yonnic commented on GitHub (Apr 22, 2025):
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home.
You need a residential IP proxy to make this work
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
@ubranch commented on GitHub (Apr 22, 2025):
> guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb.
I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
@yonnic commented on GitHub (Apr 22, 2025):
> > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
>
> so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb.
I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
Got it, thanks dude. Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
@ubranch commented on GitHub (Apr 22, 2025):
> > > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
> >
> >
> > so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
>
> yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
>
> As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
Got it, thanks dude. Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
@wukko commented on GitHub (Apr 23, 2025):
> Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
@ubranch commented on GitHub (Apr 23, 2025):
> > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
>
> you’re not able to do that lmfao good luck
how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
are you capable of sucking my balls or do u need claude 3.5 for that
@crackticker commented on GitHub (Apr 23, 2025):
> > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
> >
> > you’re not able to do that lmfao good luck
>
> how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
>
>
are you capable of sucking my balls or do u need claude 3.5 for that
Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
not sure what you get from your embarrassing whining, but you’re one of the dumbest people i’ve seen in our issues yet. have fun, and i hope you grow out of being a useless poser eventually :)
@wukko commented on GitHub (Apr 23, 2025):
> > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
> >
> >
> > you’re not able to do that lmfao good luck
>
> how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
not sure what you get from your embarrassing whining, but you’re one of the dumbest people i’ve seen in our issues yet. have fun, and i hope you grow out of being a useless poser eventually :)
Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
you’re not able to do that lmfao good luck
ofc i can't 👍🤡
@ubranch commented on GitHub (Apr 23, 2025):
> > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
>
> you’re not able to do that lmfao good luck
ofc i can't 👍 🤡

good job at putting a one-time solution token into a http request! you’re not bypassing turnstile though :(
@wukko commented on GitHub (Apr 23, 2025):
> ofc i can't 👍 🤡
good job at putting a one-time solution token into a http request! you’re not *bypassing* turnstile though :(
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
i set up my cobalt api as an AWS ECS service and passed the oxylabs residential proxy URL into API_EXTERNAL_PROXY but now it gives me a fetch failed error. Am I missing something? If it helps, I have auth turned off but only because the URL to my instance is only exposed through a private DNS namespace.
My cobalt container logs are empty, this is the response I'm getting from the cobalt container when calling it in my FastAPI script.
@ansharyan03 commented on GitHub (Apr 25, 2025):
> > > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
> >
> >
> > so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
>
> yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
>
> As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
i set up my cobalt api as an AWS ECS service and passed the oxylabs residential proxy URL into API_EXTERNAL_PROXY but now it gives me a fetch failed error. Am I missing something? If it helps, I have auth turned off but only because the URL to my instance is only exposed through a private DNS namespace.

My cobalt container logs are empty, this is the response I'm getting from the cobalt container when calling it in my FastAPI script.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @otakukz17 on GitHub (Mar 23, 2025).
problem description
After correctly configuring the
yt-session-generator, the API continues to return a YouTube authentication error for all video requests.In the Docker logs:
cobalt API ^ω^
url: http://129.151.212.247:9000
port: 9000
[✓] poToken & visitor_data loaded successfully!
[✓] api keys loaded successfully!
your instance configuration
@ccf-zeno commented on GitHub (Mar 24, 2025):
一样的问题,求助
@ubranch commented on GitHub (Mar 26, 2025):
same problem
@2shiraz commented on GitHub (Mar 26, 2025):
problem is with the ip of wherever you are hosting.
@danilt2000 commented on GitHub (Apr 7, 2025):
i have the same problem please help
@elkofy commented on GitHub (Apr 11, 2025):
I have the same problem too I can't figure out why since it works on my machine without youtube session generator.
@FethiAmari commented on GitHub (Apr 16, 2025):
Hello bro can you help me how can i contact you
@yonnic commented on GitHub (Apr 22, 2025):
guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home.
You need a residential IP proxy to make this work
@ubranch commented on GitHub (Apr 22, 2025):
so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
@yonnic commented on GitHub (Apr 22, 2025):
yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb.
I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.
As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
@ubranch commented on GitHub (Apr 22, 2025):
Got it, thanks dude. Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
@wukko commented on GitHub (Apr 23, 2025):
you’re not able to do that lmfao good luck
@ubranch commented on GitHub (Apr 23, 2025):
how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
@crackticker commented on GitHub (Apr 23, 2025):
are you capable of sucking my balls or do u need claude 3.5 for that
@wukko commented on GitHub (Apr 23, 2025):
not sure what you get from your embarrassing whining, but you’re one of the dumbest people i’ve seen in our issues yet. have fun, and i hope you grow out of being a useless poser eventually :)
@ubranch commented on GitHub (Apr 23, 2025):
ofc i can't 👍 🤡

@wukko commented on GitHub (Apr 23, 2025):
good job at putting a one-time solution token into a http request! you’re not bypassing turnstile though :(
@ansharyan03 commented on GitHub (Apr 25, 2025):
i set up my cobalt api as an AWS ECS service and passed the oxylabs residential proxy URL into API_EXTERNAL_PROXY but now it gives me a fetch failed error. Am I missing something? If it helps, I have auth turned off but only because the URL to my instance is only exposed through a private DNS namespace.
My cobalt container logs are empty, this is the response I'm getting from the cobalt container when calling it in my FastAPI script.
@elkofy commented on GitHub (May 4, 2025):
🍿 🍿 🍿