mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-15 21:31:24 -05:00
Pangolin slowing down Plex / Emby requests #747
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#747
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Kh3nsu on GitHub (Oct 27, 2025).
Describe the Bug
Hey there,
I just recently switched to Pangolin as my reverse proxy and outsourced the connection to a small VPS. So far so good, I was able to implement all ressources and services. They are all accessible over the Browser and are working fine.
The weird part is, that I noticed a playback issue in the emby app (I have to wait like 30 seconds for the playback to start) but everything else is working normal like browsing. The playback in the emby app takes a while until it starts. It is not a transcoding issue or anything, because the server does get the request but is waiting for something. You can see this in the embyserver logs at timestamp 2025-10-27 16:51:18.412.
The response finally arrives at 2025-10-27 16:51:48.907
Emby Android logs are also attached. (Time is off by one hour)
EDIT: Attachements see in my next comment
EDIT2: Attachment
embyserver_slow_response.txt
emby_android_1761582858832.txt
I sadly did not find any Pangolin logs. Under config/logs the directory is empty.
Plex does not even recognize the server anymore (In the Android App).
Over the Browser, both services are readily accessible and are working with full performance.
As soon as I turn on my VPN and the traffic is routed over my internal reverse proxy (Caddy), everything is working as it should again. No 30 second delay.
So the weird thing is, why does the reverse proxy work totally fine in a browser with those services, but as soon as I use the apps of those services, they suddenly work slow or not at all?
This behavior sadly started with Pangolin, so I first start to look here. Also as it is happening with Plex and Emby.
I appreciate any ideas, because currently I am quite stuck...
Best reegards,
Kevin
Environment
To Reproduce
Setup Emby / Plex and just try to proxy those services.
Try using it with the apps.
Expected Behavior
Quicker playback / responses or services working in general.
@Kh3nsu commented on GitHub (Oct 27, 2025):
I just noticed I gave no informations about the deployment of anything.
So Pangolin is running on a hetzner VPS (2 vCPUs, 4GB RAM and 40GB Disk space) along with authentik..
It does connect over Newt to my DMZ, which contains several VMs on a Proxmox Host. Newt itself is deployed in a small Debian VM in the DMZ.
Emby and Plex are running on the same Ubuntu VM. No Firewall rules are configured. Every service can reach anything inside the DMZ.
@th3cube commented on GitHub (Oct 28, 2025):
Have you tried to run Newt in --native mode?
https://docs.pangolin.net/manage/sites/configure-site#client-tunneling-modes
Don't know how much you pushing through that tunnel but maybe with a try ...
@Kh3nsu commented on GitHub (Oct 29, 2025):
Thank you for the response @th3cube
Sadly this did not improve the behaviour :/
The weird thing is, emby does exactly start (after trying to initialize the playback) after 30 seconds...
This more feels like a limitation or throttle than a real performance issue. Is there something that could throttle or block too many requests on pangolin?
@Kh3nsu commented on GitHub (Oct 29, 2025):
Forget what I asked. I solved it.
It was an issue with DNS entries... IT is always DNS -.-
@Cavustius commented on GitHub (Oct 31, 2025):
What were the DNS issues?
@Kh3nsu commented on GitHub (Oct 31, 2025):
Actually quite embarrassing... I simply forgot a number in the ipv6 address of the AAAA record in cloudflare.... Therefore only ipv4 resolved correctly and was reachable. Plex seemed to not work at all then and lock on ipv6, but emby probably did a failback to ipv4 on playback.
Never thought of that as everything else seemed to work -.-