It’s a total guess but is it possible your users have discovered and are accessing your content app directly?
Only from the look of that nginx conf, you appear to be using http://mymainapp.fly.dev and that would be public, by default (assuming someone knows that URL e.g it’s appeared in Google or something). I’d recommend looking at the logs of your content app to see what is being requested. If you see lots of requests for e.g /path/to/video.mp4 (or whatever content you are serving) from some IP/user agent, that would suggest someone is accessing it.
If it’s that, it might be worth looking at making your content app private (without an assigned public IP) which would mean your nginx proxy is the only thing able to access it. Take a look at Fly’s internal domains:
That would presumably also mean the data stays within Fly’s network, app->app. I’m not sure what happens billing-wise when one app requests data from another via the name.fly.dev.
An app can be made “private” by not assigning any public IP (or removing one already allocated - Fly may allocate a shared one by default … not sure).
Since every app automatically gets access to the private networking documented on that page e.g app-name.internal can only be resolved to an IPv6 by other apps within your organisation.
I’d recommend making a new app and proxy to experiment with (e.g edit its fly.toml) before making any change to your production apps. Since it may take some experiments with the hostname and port to get it working how you need.
This is assuming that public-access was the problem to begin with. If not … you’ll still get the same bandwidth usage.