Troubleshooting Network Connectivity Errors
Overview
eazyBackup transfers your data to your Storage Vault over an encrypted HTTPS connection. During a backup, the agent opens multiple parallel connections to eazyBackup's servers and keeps them open for the duration of the job. If anything on the path between your device and our servers interrupts those connections — a firewall, a security appliance, an unstable internet link, or a DNS problem — the backup job will fail with a network connectivity error.
This article explains what these errors mean, how to narrow down where the problem is occurring, and how to resolve the most common causes.
Common Error Messages
You may see one or more of the following messages in your backup job log:
wsarecv: An existing connection was forcibly closed by the remote host
An open connection was terminated mid-transfer by a device between you and eazyBackup — commonly a firewall/UTM appliance, a multi-WAN router switching internet links, or an unstable connection.
wsasend: ...
Same as above, but the interruption occurred while sending data.
tls: failed to verify certificate: x509: certificate signed by unknown authority
A firewall or security appliance on your network is performing SSL/TLS inspection and replacing eazyBackup's certificate with its own. See SSL/TLS Inspection below.
dial tcp: lookup [...]: no such host
DNS failure — your device could not resolve the eazyBackup server hostname to an IP address.
connectex: A connection attempt failed because the connected party did not properly respond...
The connection to the server could not be established at all — typically a firewall block, an outbound port restriction, or an internet outage.
net/http: request canceled (Client.Timeout exceeded while awaiting headers)
The server did not respond in time — often caused by severe packet loss, a saturated internet connection, or a proxy delaying traffic.
Couldn't save data chunk: context canceled
A follow-on message: after one upload thread fails, the agent cancels the remaining threads. Look earlier in the log for the original error.
HTTP/1.x transport connection broken
An established connection was dropped mid-request by a device on the network path.
The agent automatically retries failed transfers several times before giving up, so a single error in a log does not always mean the job failed — check the final job status.
eazyBackup Service Endpoints
Your device must be able to reach the following endpoints outbound on TCP port 443 (HTTPS/TLS). No other ports or protocols are required.
csw.eazybackup.ca
45.45.161.146
TCP 443
csw.obcbackup.com
45.45.161.146
TCP 443
s3.ca-central-1.eazybackup.com
45.45.161.149
TCP 443
If your firewall supports it, whitelist by hostname; otherwise, allow outbound TCP 443 to 45.45.161.146. and 45.45.161.149
Quick Checks First
Before deeper troubleshooting, try these steps — they resolve a large percentage of network errors:
Retry the backup. Many network errors are temporary. A repeated backup job will also usually run faster, because data chunks that were already uploaded do not need to be sent again. (Any unused chunks left behind by a failed job are cleaned up automatically by the next retention pass.)
Reboot your router/modem. Consumer and small-business routers can run out of resources when handling a large number of simultaneous connections. A reboot clears the connection table.
Check whether the error occurs at a consistent time of day. If backups only fail during business hours or during known heavy-usage periods, your internet connection may be congested. Try rescheduling the backup to a quieter time.
Check for recent network changes. New firewall, new ISP, new security software, or a firmware update on a UTM appliance immediately before the errors began is a strong lead.
If the problem persists, work through the steps below to narrow down where the connection is failing.
Step 1: Check Your Device Status in the Client Area
Log in to the client area at https://accounts.eazybackup.ca and open the Dashboard:
https://accounts.eazybackup.ca/index.php?m=eazybackup&a=dashboard
Check whether your device shows as Online.
Device is Offline: The agent cannot reach eazyBackup at all. Focus on Steps 2 and 3 below (DNS and basic connectivity), and verify your firewall allows outbound TCP 443 to the endpoints listed above.
Device is Online, but backups fail: This is an important clue. It means your device can connect to eazyBackup — the live control connection is working — but the high-volume data connections to the Storage Vault are being interrupted. This pattern points strongly at an SSL/TLS inspection appliance, a multi-WAN router, or connection instability under load rather than a simple firewall block. Continue to Steps 4–6.
You can also review your full backup job history and logs in the client area, which helps identify whether failures are constant or intermittent, and whether they always occur at the same point in the job.
Reading the job log
The job log shows exactly how far the backup got before failing. For example:
In this example, the device successfully looked up its account settings and began communicating with the Storage Vault — so DNS, routing, and the firewall rule are all working. The connection was then forcibly closed mid-session, which points at something on the network path interrupting established connections (see Steps 4 and 5).
Step 2: Verify DNS Resolution
If your log shows no such host errors, your device cannot resolve eazyBackup hostnames.
Windows (Command Prompt):
macOS / Linux (Terminal):
or
The result should return 45.45.161.146.
No result / timeout: Your DNS server is failing. Try switching your device (or router) to a public DNS resolver such as
1.1.1.1or8.8.8.8and re-test.A different IP is returned: A DNS filter, proxy, or security product may be intercepting DNS. Check any DNS-filtering services (Pi-hole, OpenDNS/Umbrella, firewall DNS filtering) for a block or override on eazyBackup domains.
Step 3: Test Basic Connectivity on Port 443
Confirm your device can open a TCP connection to the backup servers.
Windows (PowerShell):
Look for TcpTestSucceeded : True.
macOS / Linux (Terminal):
or
Connection succeeds: Basic reachability is fine — continue to Step 4.
Connection fails or times out: An outbound firewall rule, proxy requirement, or ISP/network outage is blocking the connection. Verify that outbound TCP 443 to the endpoints in the table above is permitted, and test from another device on the same network to see whether the problem is device-specific or network-wide.
Step 4: Check for SSL/TLS Inspection
This is one of the most common causes of backup connection failures on business networks.
Firewalls and Unified Threat Management (UTM) appliances — for example, FortiGate models such as the 40F or 70F, as well as SonicWall, Sophos, WatchGuard, and similar devices — often perform SSL/TLS inspection (deep packet inspection). To scan encrypted traffic, the appliance intercepts the connection and presents its own certificate to the backup software instead of eazyBackup's certificate.
The eazyBackup agent does not trust the appliance's certificate and terminates the connection. This typically appears in the log as:
Even when full inspection isn't enabled, IPS/application-control features on these appliances can silently reset long-lived encrypted connections mid-transfer, producing wsarecv: An existing connection was forcibly closed by the remote host errors instead.
How to verify:
Windows (PowerShell):
macOS / Linux (Terminal):
If the certificate issuer shows your firewall vendor or your own organization (e.g., FortiGate, Fortinet, your company's internal CA) instead of a public certificate authority, SSL inspection is intercepting the connection.
How to resolve:
Ask your network administrator to exempt the eazyBackup endpoints from SSL/TLS inspection (and from IPS/application-control profiles if resets continue). Create an exemption for:
csw.eazybackup.cacsw.obcbackup.coms3.ca-central-1.eazybackup.com
or by destination IP: 45.45.161.146 on TCP 443.
Backup traffic is already encrypted end-to-end with AES-256 before it leaves your device, so exempting it from inspection does not reduce your security posture.
Step 5: Check for Multi-WAN Routers and Load Balancing
If your site has two or more internet connections behind a dual-WAN router or SD-WAN appliance, load balancing or unstable failover can break backups.
A backup job holds connections open for minutes or hours. If the router shifts outbound traffic from one internet link to the other mid-job — because of load balancing policy or a link flapping up and down — your device's public IP address changes, the established connections to the Storage Vault break, and the job fails with An existing connection was forcibly closed by the remote host.
How to spot it:
Your device's connection history shows it connecting from multiple different public IP addresses within a short time window. (Our support team can confirm this for your account — see Contacting Support below.)
Backups fail intermittently at unpredictable points in the job, while short operations (device shows Online, small jobs) succeed.
How to resolve:
Ask your network administrator to create a policy route / persistence rule on the router that pins all traffic destined for 45.45.161.146 (TCP 443) to a single WAN interface. Most dual-WAN routers (FortiGate SD-WAN rules, pfSense policy routing, Peplink outbound policy, etc.) support per-destination rules. If one of your links is unstable, also review the failover health-check settings so the router isn't flapping between links unnecessarily.
Step 6: Test for Packet Loss and Connection Instability
If the previous steps check out but backups still fail intermittently, measure the quality of the connection.
Ping test
Windows (Command Prompt):
macOS / Linux (Terminal):
Review the summary at the end. 0% packet loss is the goal; even 1–2% loss can cause failures on large, long-running transfers. Also note the latency — consistent round-trip times are good; wildly varying times suggest congestion or an unstable link.
To identify where loss occurs on the path:
Windows:
macOS:
Linux (if installed):
Loss at the first hop points at your local network or router; loss beyond that points at your ISP.
TCP retransmission test (Windows)
This measures how many packets had to be re-sent during an actual backup:
Open Command Prompt and run:
Note the current values of Segments Sent and Segments Retransmitted.
Run a manual backup and wait for it to finish (or fail).
Run the same command again and compare. Divide the increase in retransmitted segments by the increase in sent segments to get the retransmission rate during the backup.
macOS:
Linux:
A retransmission rate under 1% is normal. Rates of several percent or higher indicate packet loss on the path — typically a saturated upload link, Wi-Fi interference, faulty cabling, or an ISP issue.
Common fixes:
Use a wired connection instead of Wi-Fi for the backup device if possible.
Enable bandwidth throttling in the eazyBackup agent so the backup doesn't saturate your upload link (a saturated link drops packets).
Reduce the backup's concurrent connections if your router struggles with many simultaneous streams.
If loss appears beyond your router in the path tests, contact your ISP with the results.
Step 7: Check Local Security Software, Proxies, and VPNs
Software on the device itself can also interfere with backup connections:
Antivirus / endpoint protection with HTTPS scanning: Products that scan encrypted web traffic behave just like the SSL-inspecting firewalls in Step 4. Add exclusions for the eazyBackup agent application and the three endpoints listed above.
Proxy servers: If your network requires a proxy for internet access, confirm the backup agent's proxy settings are configured, or exempt the eazyBackup endpoints from the proxy.
VPN clients: A VPN that routes all traffic through a remote gateway adds latency and another point of failure. Test with the VPN disconnected, or configure a split-tunnel exception for
45.45.161.146.
Contacting Support
If you've worked through these steps and backups are still failing, our team is happy to dig in. Please open a ticket from the client area at https://accounts.eazybackup.ca and include:
The account name and device name affected.
The full job log from a recent failed backup (Job Logs → Report in the Control Panel).
The date and time the failures began, and whether they're constant or intermittent.
The results of any tests from this article you've run (ping/packet loss results, certificate issuer check,
Test-NetConnectionoutput).Details about your network: firewall/UTM make and model, whether SSL inspection is enabled, and whether the site has more than one internet connection.
With this information, we can compare against our server-side connection logs — including which public IP addresses your device has been connecting from — and usually pinpoint the failure point quickly.
Last updated