Why Your Site Is Slow Only for Visitors on One Indonesian ISP

A customer says their site is slow or timing out, but only for visitors on one ISP. IndiHome users wait a long time or give up. People on other providers load the page normally, and so does the same phone after switching to a different carrier. The first instinct is to blame the server. Usually the server is fine, and the problem sits somewhere on the path between that ISP and the data center. This walkthrough starts from that symptom and ends with a root cause you can show someone. Either the server is at fault, or a congested link between the ISP and an Indonesian internet exchange is. Internet exchanges such as IIX (run by APJII) and OpenIXP are places where ISPs and data centers connect directly, or peer, so domestic traffic stays in the country with fewer hops, lower latency, and no international transit cost. When an ISP's connection into one of those exchanges fills up, only that ISP's users feel it.

Get the shape of the complaint first

Before touching the server, pin down who is affected and when. These details decide which direction you investigate. Ask which ISP, and be specific. Fixed broadband and mobile data from the same company group can take different paths. Ask whether other local sites feel slow on the same connection, because a slow path often affects many domestic sites at once while international sites stay normal. Ask when it happens. Slowness that appears in the evening and disappears late at night tells a very different story than a site that never loads at all. The most useful question is whether a VPN makes it fast. A VPN does not change your server. It only changes the route the traffic takes. If the site loads normally through a VPN on the same connection, you have a strong hint that the path is the problem.

Rule out the server before blaming the network

Escalating a network issue when the real cause is an overloaded PHP pool wastes everyone's time, so check the server side first. Look at load, PHP worker saturation, and error logs at the times the customer reported. Then measure how the site responds from somewhere outside the problem ISP, and from the server itself.

BASH

# Run from a machine on a different ISP, then from the server itself.
# Compare the phases: network delay shows up in connect/tls, server delay in ttfb.
curl -o /dev/null -s -w 'dns: %{time_namelookup}
connect: %{time_connect}
tls: %{time_appconnect}
ttfb: %{time_starttransfer}
total: %{time_total}
' https://example.com/

Each value is cumulative seconds since the request started. If the gap between tls and ttfb is small everywhere, the application answers quickly once the request arrives. If a technical customer runs the same command from the affected connection and sees a large connect time, the delay happens before your server is even involved. That only gets worse with packet loss, because lost handshake packets have to be retransmitted. Next, ask the affected visitor for their public IP and search your access log for it with something like grep '203.0.113.45' against the right log file. The path depends on the stack. Nginx often logs to /var/log/nginx/access.log, and cPanel keeps per-domain logs in its domlogs directory. If the requests are there with normal status codes, the server answered and the delay is on the way back. If there is no entry at all, the request never arrived or was dropped earlier. Two red herrings deserve a quick check here. The first is a firewall ban. Mobile carriers and some fixed ISPs use carrier-grade NAT (CGNAT), which means many subscribers share one public IP. If Fail2ban, CSF, or a WAF blocked that IP because of one abusive user, a large group of that ISP's customers gets locked out at once. The signature is consistent hard timeouts or refusals for everyone behind that IP, at any hour, rather than slowness that rises and falls. Search your firewall's deny lists for the visitor's IP. The second is DNS. If one ISP's resolvers still hold an old record after a migration, those users hit the old server. Ask the customer to run nslookup for the domain on the affected connection and confirm that it returns your current IP.

Trace the path with MTR in both directions

Once the server looks clean, you need to see where the time goes. MTR combines traceroute and ping. It sends repeated probes and shows packet loss and latency for every hop along the route. Ask the customer to run it from the affected connection toward your server. On Windows, WinMTR does the same job. Then run it yourself from the server back to the customer's public IP, because internet routing is often asymmetric: the return path can cross completely different networks.

BASH

# From the server back to the affected visitor (report mode, 100 probes, show IPs and AS numbers)
mtr -rwbz -c 100 203.0.113.45

# From the customer side toward the site, using TCP 443 in case ICMP is filtered
mtr -rwbz -c 100 --tcp --port 443 example.com

A congested interconnect usually looks something like this.

TEXT

Illustrative output format (addresses, names and values are placeholders)
HOST: web01                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gw.dc.example.net (198.51.100.1)           0.0%   100    0.5   0.6   0.3   1.1   0.1
  2.|-- core1.dc.example.net (198.51.100.9)        0.0%   100    1.0   1.2   0.8   2.4   0.2
  3.|-- ix-peer.example.net (192.0.2.10)           0.0%   100    2.1   2.3   1.9   4.0   0.3
  4.|-- isp-border.example.net (192.0.2.77)       14.0%   100  118.4 121.7  64.2 210.5  30.1
  5.|-- isp-core.example.net (203.0.113.1)        40.0%   100  119.9 123.0  66.0 215.3  31.4
  6.|-- 203.0.113.45                              13.0%   100  120.2 122.5  65.7 212.8  30.9

Read it from the end backwards. The final hop shows real loss and a big latency jump, and both first appear at hop 4, where traffic crosses from the exchange into the ISP. Hop 5 shows even higher loss, but the final hop does not inherit it. That extra loss is almost certainly the router deprioritizing replies to probes aimed at itself, not dropping real traffic. Loss only counts when it starts at a hop and carries through to the destination. For a longer guide to reading customer MTRs, see this walkthrough on reading MTR for IIX peering problems. The -z flag adds AS numbers, which tell you which network owns each hop, so you can see exactly where your data center's network ends and the ISP's begins. Hostnames sometimes mention the exchange too, but that depends on how each operator names its interfaces.

Confirm it is the ISP's port, not a one-off

One MTR is a snapshot. Before calling it, compare two things. Compare ISPs. Run the same test toward the same server from a different provider, such as a mobile hotspot on another carrier or a colleague's home connection. If the ISP publishes a looking glass (a public tool for running traceroutes from inside its network), use that as well. If every other path is clean and only one ISP shows loss at its boundary, you have isolated the problem. Compare times. Repeat the test at a quiet hour, such as early morning, and again during the evening peak. A saturated port behaves in a recognizable way. It is clean off-peak, then latency climbs and loss appears as traffic grows. Once an ISP's physical port toward IIX or OpenIXP reaches its maximum bandwidth, for example a 10 Gbps or 40 Gbps port, packets start queuing and dropping. Latency can jump by tens to hundreds of milliseconds, even though the subscriber's own plan has plenty of bandwidth. Route instability looks different. If the path itself changes between runs, with different hops or different networks, or if drops are sudden and intermittent rather than tied to peak hours, you may be seeing BGP routes flapping, meaning routes repeatedly being withdrawn and re-announced, or a hardware fault such as a failing optical transceiver on the exchange port.

Pattern you see	Where the problem most likely sits
Slow from every ISP, high ttfb on the server itself	Server or application
Hard timeouts for one ISP at all hours, clean MTR	Firewall ban on a shared CGNAT IP, or stale DNS
One ISP slow, worse at peak, loss starts at the ISP or exchange boundary and persists	Congested interconnect port
Path changes between runs, sudden intermittent drops	Route flapping or failing hardware on the link

What you can do when the bottleneck is not yours

The real fix sits with the ISP. When a port is saturated, the solution is to upgrade it, for example from 10G to 40G or 100G, or to add more interconnect capacity. Network operators also monitor port utilization to spot congestion early, and they apply BGP route dampening to suppress unstable routes. None of that can be done from a hosting account. What you can do is make the problem easy to act on. Send your data center's NOC, or your upstream provider, a short package: the affected ISP, the visitor's public IP, MTR results in both directions with timestamps, and an off-peak versus peak comparison. Depending on their setup, they may be able to steer traffic for that ISP through a different path, or raise the issue with the ISP directly. A vague message saying the site is slow on IndiHome rarely gets that far. For the customer, be honest. Explain that the server is responding normally, show the evidence, and suggest a VPN as a temporary workaround for affected users. A CDN or reverse proxy changes the path too, but it only helps if its own route to that ISP avoids the congested link, so test it with the same MTR method before recommending it. If this keeps happening for a site whose audience sits mostly on one network, server location becomes a real consideration. The trade-offs are covered in choosing between Indonesian and Singapore server locations. When only one ISP complains, work in order: confirm the server answers quickly, rule out shared-IP bans and stale DNS, then let MTR in both directions show you where loss begins. If that point is the ISP's edge toward the exchange and it gets worse at peak hours, you have your answer. At that stage, the most useful thing you can do is hand clear evidence to the people who can upgrade that port.