How do I distinguish provider-edge filtering from a local firewall or application failure?
A request can fail before reaching the server, at the host firewall or after reaching an application. Provider-edge filtering and DDoS mitigation operate outside the OS’s direct control. A local firewall cannot recover an already-saturated upstream link, so collect evidence from both the host and the provider when the path is uncertain.
Before you start
- Authorised access to the dedicated server and the named inspection tools.
Instructions
1. Confirm the local listener and link state
Inspect the expected service port and current link counters. A listening port does not prove that a firewall or upstream route permits external access.
ss -ltn
ip -s link show dev enp1s0Use the exact expected address/port and physical interface. Keep host firewall inspection read-only through its configured management tool.
2. Correlate an authorised external test
Record source, destination, protocol and UTC time for a controlled connection attempt. Ask the provider whether routing, null-routing, rate limits or mitigation events affected that specific flow. Do not disable the host firewall to bypass an unexplained failure.
Check the result
- The failure is located at an evidenced layer, and the scoped correction is verified from the same authorised path while intended protections remain in place.
Troubleshooting
- Local health checks pass but external access fails
- Inspect binding, host rules and upstream route/filter evidence separately.
- The link is saturated by unwanted traffic
- Coordinate the provider’s supported upstream mitigation rather than relying solely on host rules.
- Ping works but the application fails
- ICMP success does not validate the application’s TCP/UDP path or policy.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.