Fix Duplicator backups failing with cURL error 18 or 56 on Hostinger

Hourly incremental backups on my own site started failing in late October. The build finished cleanly every time, then the transfer to Duplicator Cloud died partway through with a cURL error. Here is what was actually wrong, and the two settings that fixed it.

What you see

• The backup builds to 100% and only then fails, on the transfer to remote storage.
• The log shows cURL error 18: transfer closed with outstanding read data remaining, or cURL error 56: Recv failure.
• A transfer that should take seconds grinds on for 20 to 30 minutes before giving up.

Why it happens

Nothing is wrong with the backup or your storage credentials. Hostinger resolves the storage endpoint over IPv6, and that path drops long-lived connections partway through. cURL reports the truncation, Duplicator reports a failed transfer, and the obvious suspects, memory limits and file size and timeouts, all look innocent because they are.

The fix

1. In WordPress, open Duplicator Pro, then Settings, then General.
2. Turn on IPv4 only. This forces every outbound transfer onto IPv4, and it is the setting that actually resolves the truncation.
3. Set Server load reduction to 1. On shared hosting this stops the transfer being throttled mid-flight.
4. Save, then trigger your schedule manually instead of waiting for the next hourly run.

If you prefer to check the stored values directly, these are the two that matter:

ipv4_only: true
server_load_reduction: 1

How to confirm it worked

1. Watch the transfer time on the next run. Mine went from roughly 28 minutes and failing, to 7.7 seconds and clean.
2. Confirm the backup actually appears in your cloud storage at the size you expect.
3. Let one scheduled hourly run fire on its own before you call it fixed.

If transfers still fail after forcing IPv4, stop looking at Duplicator. An HTTP 403 on upload points at an expired or zero-capacity storage container, which is a billing problem wearing a network problem’s clothes.