Custom Media on players will work with IPs, but not with a CNAME or A/AAAA pointing to the IP

I have a question regarding custom media in condos; specifically I’m trying to do this on my dedicated condo, but I’ve also been trying on a local condo throw up in single player mode. For a few years now I’ve been trying to work this out, but cannot find a way to accomplish it.

I have my own domain; one of the subdomains I have configured serves a shimmie2 (booru board) instance, which supplies my own image hosting for canvases in my dedicated condo; both are running in seperate docker containers on a dedicated server I have, under a hypervisor (unraid).

I have been trying to figure out a way to play custom media; I have the codec down pat now, but cannot get anything to play with my domain, using a subdomain for another docker server, this one just an nginx server, set up to allow direct files to the media I have, in WEBM format.

If I format the links into the media players in my condos like http://<IPv4>:<port>/path/to/file.webm it worked, but it would never work with my domain, like https://my.domain.com/path/to/file.webm even though the domain would point straight to the IP address. I tried both as a CNAME to the A record I was updating for the base domain, with an nginx proxy manager set up in another docker container to serve requests for the subdomain to the docker container that actually has it.

These days I’m now on Starlink (thank god, good riddance Spectrum-Charter, I sincerely wish they would actually fix all the crap around me that’s been broken since they laid it out 50 or 60 years ago), so I’m now trying with http://<IPv6>/path/to/file.webm and https://my.domain.com/path/to/file.webm instead, but I’m finding the same things.

With the IP addresses, it works perfectly fine, playing in game for anyone that can do native IPv6 resolution themselves, and resolving in my nginx access.log files as <External IPv6 address> - - \[11/Jul/2026:10:48:49 -0400\] "GET </path/to/file.webm> HTTP/1.1" 206 14723346 "media-cache.towerunite.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Tower/++UE4+Release-4.22-CL-0 UnrealEngine/4.22.3-0+++UE4+Release-4.22 Safari/537.36", but when I try with the domain name, no matter how I format it (including as a straight AAAA to the IPv6 GUA that the docker container itself has, for the nginx server), it will never produce anything in my access.log or my error.log file

Does all custom media end up going through that media-cache address, and if so, is there some kind of like domain whitelist that would explain why it doesn’t resolve my subdomain/domain for the media players, but nothing has ever been an issue with my image hosting, likely because there’s no cache there, and its on end-clients to resolve it?

The domain itself does load as direct files, and will play in web browsers. I would of course, be happy to share (in private) specifics regarding the domain I have, the subdomain I’ve had set up to try to get this working, how I’m routing said DNS records for this as well as my self-hosted image server, using cloudflare, etc. if it would be able to help me narrow it down.

I checked out my domain configuration and I’m currently not using any public records, I’m using Cloudflare Tunnel on my server. When I had made that initial post with the roundabout instructions I was just using a free A record no-ip domain, though.

Hrm, interesting - I know how to set up tunnels with cloudflared/zero trust - gone ahead and stopped my ddns writer for the subdomain I’m using, deleted the DNS record for it manually, and set up the tunnel to use it instead.

With the published application route on the tunnel in cloudflare, its working in the browser still, but still refuses to playback in game. Using the current ipv6 gua still works for the exact same path/file :sob:

I know you mentioned your friends can play your video in their browsers, but have you had anyone else try loading your hosted video on a Tower Unite player?

I did; I had two friends both able to open the link in their browsers and paste it into the game, after I made them media admins, and it was still just a blank, black screen

edit: I’ve got multiple files/links I’ve been trying with as well, not just one file. For each, I can get it to work if I format the link with the ipv6 address, but not with the domain

What about any Cloudflare security settings, do you have any events that show under there? Maybe the mediacache fetcher from TU is getting blocked by some kind of bot filter? The thing is that I have Bot Prevention and other security features enabled and I don’t have issues with them on. But your issue is completely isolated to the domain, so it HAS to be something in your host’s portal.

I don’t think so? I have bot prevention enabled as well, but aside from that and DDoS protection, I don’t recall having set up any further cloudflare security stuff explicitly - the media cache’s ip from nslookup also isn’t showing up anywhere in my security section under cloudflare.

Given I don’t see the hostname or IP the media cache currently returns for me, I don’t know how much use making a manual security rule is, but I’m making one so if hostname == media-cache.towerunite.com all waf components are to be skipped, maybe that’ll accomplish something? I’m not sure the media cache has a static IP, but again, neither the hostname or the current IP come up in my logs on cloudflare.

Most of it alarmingly is tagged as Microsoft, from the US, trying a lot of non-existent endpoints on a service that isn’t even up, and wouldn’t allow for those endpoints anyway, because they don’t exist, and the reverse proxy doesn’t allow anything out for the container in question anyway. Excluding that, its a bit of Spain addresses doing the same for yet another container, where the endpoint doesn’t exist and the reverse proxy wouldn’t be allowed, and one singular entry from Lithuania, trying a known CVE against another seperate subdomain, which was rightly caught and blocked.

My domain is also purchased straight from cloudflare, under the .dev TLD, aside from also being used for DNS records. Maybe that makes some kind of difference? That entire TLD is HSTS, and I do have full (strict) SSL certificates signed by cloudflare in operation; are you doing similar?

My domain is purchased from Dynadot, using Cloudflare’s nameservers and served through cloudflared tunnel. I use a .boo TLD which is also on the HSTS preload list so it’s probably not that…I think the main difference in our setup here is that you’re running nginx proxy manager and I’m not.

Can you curl your video spoofed as the TU user agent and referrer and check the headers?

In Windows:

curl.exe -v -o NUL -r 0-1023 -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Tower/++UE4+Release-4.22-CL-0 UnrealEngine/4.22.3-0+++UE4+Release-4.22 Safari/537.36" -e "https://media-cache.towerunite.com/" https://your.domain/video.mp4

Check for:

  1. HTTP 206 Partial Content response
  2. Content Type is video/mp4
  3. content-range is present and total after slash matches file size
  4. presence of cf-mitigated

Here’s an example of this against my hosted mp4:

* IPv6: (none)
* IPv4: <CF-ANYCAST-1>, <CF-ANYCAST-2>
*   Trying <CF-ANYCAST-1>:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Established connection to example.tld (<CF-ANYCAST-1> port 443) from <LAN-IP> port <PORT>
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
  0      0   0      0   0      0      0      0                              0* using HTTP/1.x
> GET /path/to/file.mp4 HTTP/1.1
> Host: example.tld
> Range: bytes=0-1023
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Tower/++UE4+Release-4.22-CL-0 UnrealEngine/4.22.3-0+++UE4+Release-4.22 Safari/537.36
> Accept: */*
> Referer: https://media-cache.towerunite.com/
>
* Request completely sent off
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 206 Partial Content
< Date: Thu, 30 Jul 2026 21:07:22 GMT
< Content-Type: video/mp4
< Content-Length: 1024
< Connection: keep-alive
< Age: 84
< etag: "<REDACTED>"
< last-modified: Sat, 13 Jun 2026 04:30:37 GMT
< Server: cloudflare
< content-range: bytes 0-1023/11763387
< Cache-Control: max-age=14400
< cf-cache-status: HIT
< Nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
< Report-To: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=<REDACTED>"}]}
< CF-RAY: <REDACTED>
< alt-svc: h3=":443"; ma=86400

{ [668 bytes data]
100   1024 100   1024   0      0   5970      0                              0
* Connection #0 to host example.tld:443 left intact```