When the satellite link is not the problem

At a site with a satellite link, that link is blamed for every fault. It is expensive, it is not understood locally, and it is the obvious difference from every other office. It is also frequently innocent.

Check the link’s own health first

Signal quality at baseline, post-correction errors at zero, no recent loss of lock. If all three hold, the space segment is fine and the fault is elsewhere. That takes two minutes and redirects everything that follows.

Measure the link separately from the application

Test to the far end of the satellite hop, not to a service beyond it. If the modem-to-modem path performs correctly and the application does not, the fault is past the hop.

ping -c 100 <far-end modem or hub router>
iperf3 -c <hub-side host> -u -b 5M      # avoid TCP acceleration effects

Consistent latency and no loss to the far end means a working link.

The usual real causes

A saturated link, which is a capacity problem and not a fault. An MTU mismatch introduced by a tunnel across the link. A DNS resolver on the wrong side, so every lookup crosses the satellite and adds 600 ms to every action. An application with a chatty protocol that was never tested at this latency. A local LAN fault at the remote site that nobody checked because the satellite was more suspicious.

The DNS case specifically

This one is worth its own mention because it is so common and so invisible. A remote site resolving through a server at the hub pays a full round trip on every lookup, and a single page can generate dozens. Users describe it as “the internet is slow here”. A local caching resolver frequently transforms the experience with no change to the link.

Before you escalate

Have the numbers: signal quality against baseline, error rates, a latency and loss measurement to the far end, and a statement of what works and what does not. A well-evidenced escalation gets a real investigation. “The satellite is slow” gets a status page link.