> For the complete documentation index, see [llms.txt](https://docs.eazybackup.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eazybackup.com/troubleshooting/troubleshooting-network-connectivity-errors.md). # 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: | Error message | What it usually indicates | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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. | Hostname | IP address | Port | | -------------------------------- | ------------- | ------- | | `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: 1. **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.) 2. **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. 3. **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. 4. **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](https://accounts.eazybackup.ca/) and open the **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: ``` 12:00:01 I Looking up account settings... 12:00:01 I Running backup rule Company Every Hour 12:00:01 I Checking connection to Storage Vault... 12:00:02 I Finding backup job(s) in Storage Vault... 12:00:11 E snapshots: Loading snapshot: read tcp 10.16.2.4:62380->45.45.161.146:443: wsarecv: An existing connection was forcibly closed by the remote host. ``` 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): ``` nslookup csw.eazybackup.ca ``` **macOS / Linux** (Terminal): ``` dig +short csw.eazybackup.ca ``` or ``` nslookup csw.eazybackup.ca ``` 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.1` or `8.8.8.8` and 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): ```powershell Test-NetConnection csw.eazybackup.ca -Port 443 ``` Look for `TcpTestSucceeded : True`. **macOS / Linux** (Terminal): ``` nc -vz csw.eazybackup.ca 443 ``` or ``` curl -v https://csw.eazybackup.ca --connect-timeout 10 ``` * **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: ``` Can't access Storage Vault: Retried 3 times over 0:04: Post "https://csw.eazybackup.ca/api/v1/bucket/checkauth": tls: failed to verify certificate: x509: certificate signed by unknown authority ``` 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): ```powershell $tcp = New-Object Net.Sockets.TcpClient('csw.eazybackup.ca', 443) $ssl = New-Object Net.Security.SslStream($tcp.GetStream()) $ssl.AuthenticateAsClient('csw.eazybackup.ca') $ssl.RemoteCertificate | Format-List Subject, Issuer ``` **macOS / Linux** (Terminal): ``` openssl s_client -connect csw.eazybackup.ca:443 -servername csw.eazybackup.ca < /dev/null 2>/dev/null | openssl x509 -noout -issuer -subject ``` 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.ca` * `csw.obcbackup.com` * `s3.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): ``` ping -n 100 csw.eazybackup.ca ``` **macOS / Linux** (Terminal): ``` ping -c 100 csw.eazybackup.ca ``` 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:** ``` pathping csw.eazybackup.ca ``` **macOS:** ``` traceroute csw.eazybackup.ca ``` **Linux** (if installed): ``` mtr csw.eazybackup.ca ``` 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: 1. Open Command Prompt and run: ``` netstat -s -p tcp ``` Note the current values of **Segments Sent** and **Segments Retransmitted**. 2. Run a manual backup and wait for it to finish (or fail). 3. 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:** ``` netstat -s -p tcp | grep -i retrans ``` **Linux:** ``` nstat -az TcpRetransSegs TcpOutSegs ``` 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](https://accounts.eazybackup.ca/) and include: 1. The **account name and device name** affected. 2. The **full job log** from a recent failed backup (Job Logs → Report in the Control Panel). 3. The **date and time** the failures began, and whether they're constant or intermittent. 4. The results of any tests from this article you've run (ping/packet loss results, certificate issuer check, `Test-NetConnection` output). 5. 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.