On Linux, ip route get asks the kernel how it would route traffic to a destination without sending packets to that destination. It is useful when you need to identify the selected interface, next hop and preferred source address before changing a VPN or gateway. A successful lookup is not evidence that the remote server is reachable or that an application can connect.
Start with a numeric destination
Open a terminal in the environment where the failing application runs. For a harmless example, use this documentation address as a routing-lookup target:
ip -4 route get 192.0.2.1This command does not contact a service at that address. For an actual investigation, substitute the numeric IPv4 destination involved in the problem. Using a numeric address keeps name resolution out of this particular observation. Do not treat the example address as a public test server or use its route result as evidence about your own application destination.
Run the command as your ordinary user initially. If the utility is missing, check your distribution’s iproute2 package documentation through your normal software-management process. Do not paste a route-add command from a search result merely because the lookup command is unavailable.
Read the route fields, not just success or failure
For illustration only, a result might contain the following fields. These values are hypothetical, not measured output from your machine:
192.0.2.1 via 10.0.0.1 dev eth0 src 10.0.0.20viaidentifies the selected next-hop gateway when one is present.devnames the selected output interface.srcidentifies a preferred source address for this lookup.
A directly connected destination may not require a gateway field. Interface names and additional output vary, so do not use this illustration as a template that every successful response must match. Preserve error text too: an unreachable result is useful evidence, not a reason to delete existing routes.
Check whether the selected interface fits your intended path. A company-only destination going through an unexpected interface is a useful escalation clue. It is not, by itself, proof of the correct replacement route or authorization to change the VPN configuration.
Understand why route get differs from route show
The iproute2 manual distinguishes listing existing routes with show from resolving a particular destination with get. A destination lookup answers a narrower question than reading a default route and assuming every connection follows it. The manual also states that no packets are actually sent during this operation.
However, ‘no destination packets’ is not a promise that the kernel performs absolutely no internal work: the documentation describes resolving routes and creating clones if necessary. The practical safety boundary is that the example does not add, replace, delete or flush configured routes. No route-edit rollback is needed because no configuration edit is requested.
For Windows-based evidence collection instead, see our route print investigation before changing a VPN or gateway. The commands differ, but both workflows keep observation separate from a configuration change.
Keep the application context in view
A basic lookup does not model every property of an application’s traffic. The manual provides selectors for source address, protocol, ports, marks, interfaces and VRFs. If policy routing is involved, an unqualified lookup may not represent the application’s actual lookup. Likewise, a terminal outside a container may inspect a different networking environment from the application inside it.
Record which host and environment you inspected, whether the VPN was connected, the numeric destination and the time of the observation. On an authorized system, compare the same destination before and after an already-approved connection change. Do not disconnect a business VPN just to collect a comparison without considering the impact on active work.
If the route looks plausible, investigate connectivity separately with an approved test against the actual service. This lookup does not prove DNS correctness, neighbor resolution, firewall acceptance, server availability, TLS success or authentication. Conversely, one failed ping would not automatically invalidate a routing lookup.
Short evidence checklist and FAQ
- Keep the exact command, complete output and relevant environment details.
- Record the selected interface and source address without assuming they guarantee delivery.
- Redact private addressing and infrastructure names before posting publicly.
- Escalate unexpected results with evidence rather than experimenting with route deletion.
Does this measure latency? No. It resolves routing information, not a round trip.
Does it verify a VPN tunnel is healthy? No. A selected tunnel interface is not proof that traffic crosses it successfully.
Source: The iproute2 ip-route manual, particularly its ‘ip route get’ section, documents lookup behavior and the no-packets distinction.
Safety: This tutorial is for educational purposes. Test procedures carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues. Limit inspection to systems you are authorized to administer.
