Dev.to WebDev ๐Ÿ›  Dev ๐Ÿ‘ 0 ๐Ÿ“– 2 min read

Why I proxy video downloads through my own server instead of hotlinking

Every video downloader has to answer one question: when the visitor clicks Download, does the file come from your server, or do you just hand the browser the provider's URL and get out of the way? The lazy option is hot

Every video downloader has to answer one question: when the visitor clicks Download, does the file come from your server, or do you just hand the browser the provider's URL and get out of the way?

The lazy option is hotlinking. The provider API returns a media URL, you put it in an <a> tag, done. It costs you nothing in bandwidth, there is almost no code, and it works beautifully right up until it doesn't.

On ramrom.io I proxy nearly every download through my own small PHP script, and that was a deliberate choice made after watching hotlinking fail in every way it can fail.

The first failure: hotlinked URLs expire

Most provider APIs return signed URLs โ€” links with a token embedded that die after minutes or hours. If a visitor resolves a video, gets distracted, and clicks Download twenty minutes later, the hotlink is a dead link. With a proxy, the resolve step and the fetch step happen back to back on my server, so expiry never reaches the visitor.

The second failure: the browser plays instead of downloading

Point a browser straight at an MP4 and it will happily play it inline. To force an actual download you need Content-Disposition: attachment on the response, and you can only set that header if the file passes through your server. My proxy reads the provider's response and re-emits it with the right filename and the right disposition, so the visitor gets tiktok-video-2026.mp4 in their downloads folder instead of a video player tab they then have to wrestle with.

The third failure: the URL is an error page wearing a disguise

Providers return 200 OK with an HTML error body more often than anyone admits. Hotlinking serves that HTML straight to the visitor, who now has a file called .mp4 that is actually a login wall. My proxy sniffs the Content-Type of what comes back and refuses to relay anything that isn't a video or audio type, turning the failure into an honest error message instead of a corrupt file.

The price: my bandwidth

There is no hiding this โ€” proxying means every byte of every video travels through my hosting account. On shared hosting that is a real budget. I keep it honest by never storing the files: the proxy streams the provider's response straight to the visitor with a bounded buffer, so disk usage stays at zero and each download only costs the transfer.

There is one case where I still hotlink: some providers serve from infrastructure that returns empty responses to datacenter IPs. When my server asks, it gets nothing, but the visitor's own browser gets the file fine. Those formats are flagged as direct links. Everything else goes through the proxy.

The code itself is unglamorous โ€” cURL, a five-redirect cap, a content-type check, and headers for the filename. But that unglamorous middle layer is where a downloader earns the word "download". Without it, you haven't built a downloader; you've built a link forwarder that fails in the visitor's face instead of yours.

๐Ÿ“ฐ Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.