# How Support Differentiates Server vs Network Issues

Source: https://urbanx.co.za/knowledge-hub/support-diagnostics/server-vs-network-issues

**Answer:** Support differentiates server vs network issues by analysing where latency or packet loss begins in the routing path. If instability appears before the final hop, it is network-related. If only the final hop shows loss or delay, it is likely server-side.

Part of [Gamer-Centric Support & Intelligent Diagnostics](https://urbanx.co.za/knowledge-hub/support-diagnostics) · 9 min read · by UrbanX Support Engineering

## Why This Distinction Matters

When a game feels unstable, the issue may originate from:

- LAN instability
- ISP core congestion
- Peering or routing problems
- International transit
- Access-layer fibre fault
- Game server congestion or filtering

Escalating a server issue to an FNO wastes repair time. Ignoring a network fault delays resolution. Structured differentiation protects the ticket lifecycle and escalation accuracy.

## Core Diagnostic Principle

Network issues propagate forward. Server issues appear at the final hop.

If packet loss or latency begins mid-route and continues through downstream hops, it indicates network instability. If the route is stable until the final hop, it is typically server-side.

Interpretation logic reference: [How to Interpret Traceroute Results for Packet Loss](/knowledge-hub/gaming-performance/interpret-traceroute-packet-loss)

## Step-by-Step Isolation Workflow

1. **Validate Test Conditions**
   - Support confirms: Ethernet connection used, WinMTR run for 5–10 minutes, no active upload congestion, and correct game server IP tested.
   - Incorrect testing invalidates classification.
2. **Analyse Routing Path Stability**
   - Support examines latency per hop, packet loss percentage, jitter consistency, and sudden latency jumps.
   - If instability begins: at Hop 1 → LAN. Early ISP hops → ISP core. Mid-route near peering → routing. After international transition → transit.
   - See packet loss classification: [How UrbanX Diagnoses Gaming Packet Loss](/knowledge-hub/support-diagnostics/urbanx-diagnoses-gaming-packet-loss).
3. **Evaluate Final Hop Behaviour**
   - If all intermediate hops are stable and packet loss appears only at the final hop, this suggests server-side congestion, ICMP rate limiting, or game server filtering.
   - Final-hop-only loss rarely indicates fibre damage.
4. **Cross-Check Multi-User Patterns**
   - Support reviews area-level reports, similar complaints from the same game, and monitoring alerts.
   - If multiple users across different ISPs report identical behaviour, the issue is likely server-side. If only one user is affected and instability appears early in the route, the issue is network-side.
5. **Confirm WAN Sync State**
   - Access-layer faults usually include WAN sync instability, router unreachable state, and repeated disconnect patterns.
   - If WAN remains stable and only one game shows issues, server-side classification increases.
   - Escalation boundary reference: [When Does an ISP Escalate to an FNO?](/knowledge-hub/support-diagnostics/isp-escalate-to-fno)

## Server vs Network Comparison

| Indicator | Network Issue | Server Issue |
| --- | --- | --- |
| Loss begins before final hop | Yes | No |
| Loss only at final hop | No | Yes |
| WAN sync unstable | Yes | No |
| Multiple ISPs affected | Possible | Common |
| International routing jump | Possible | No |
| Escalation required | Possibly (if access-layer) | No |

> **INFO:** Escalation is never triggered for confirmed server-side congestion.

## South African Routing Context

Most major games serving South Africa are hosted in Johannesburg. If routing remains local and stable but gameplay instability occurs:

- Server-side congestion is likely
- Maintenance or patch deployment may be active

If routing exits South Africa and instability begins internationally, the issue is transit-related, not a fibre fault. The multi-FNO environment requires accurate boundary separation.

## Key Term: Final Hop

- **Final Hop** — The last routing point before the destination server in a traceroute or WinMTR output. Instability that appears only at this hop often indicates server-side behaviour rather than network infrastructure failure.

## When Escalation Is Appropriate

Escalation may occur if:

- Packet loss begins before ISP core
- WAN sync instability present
- Access-layer evidence confirmed

Escalation does not occur if:

- Only final hop shows instability
- Routing path stable
- WAN state stable

> **WARNING:** Server congestion does not justify FNO dispatch.

## Common Misinterpretations

Classification requires propagation analysis and telemetry cross-checking:

- Final-hop packet loss does not always indicate fibre damage
- High latency in one game does not mean network fault
- Strict NAT does not equal server issue
- International server routing does not justify escalation

## Frequently Asked Questions

**Why does only one game have issues?**

That game's server may be congested or undergoing maintenance.

**Can server issues look like packet loss?**

Yes. Final-hop ICMP filtering or server overload can mimic packet loss.

**If my speed test is fine, can it still be a server issue?**

Yes. Speed tests measure throughput, not server performance.

**Should I escalate server-side issues?**

No. Server congestion is outside ISP and FNO control.

**How can support confirm server-side problems?**

By confirming routing stability and identifying final-hop-only instability.