Ping & Website Screenshot

ICMP ping is the original "is this host alive" protocol — small echo packets sent via the IP layer. It measures pure network round-trip time without involving any higher protocol. This is what the standard ping command does.

TCP ping measures the time to complete a TCP handshake (SYN, SYN-ACK, ACK) on a specific port. It's slightly slower than ICMP because TCP has more overhead, but it tests that an actual service is responding — not just that the network layer is reachable.

For "is the website up" questions, both give equivalent answers. ICMP is preferred for raw network diagnostics; TCP is preferred when you specifically want to know "can users actually connect to this service."

High latency with no loss typically means the network path is congested but functional. Common causes:

• Geographic distance — pinging Sydney from Lagos will be 300ms+ even on perfect networks. Speed of light is the limit.
• Routing inefficiency — your traffic may be taking a roundabout path through multiple ISPs
• Server-side throttling — some hosts deprioritize ICMP, causing it to return slowly even when the actual website is fast
• Wi-Fi or mobile network on your end adds variability

Packet loss in a 4-packet sample (e.g., 25% = 1 lost) can be random and not necessarily a real problem. Consistent loss across multiple attempts (use Refresh to retry) suggests:

• ICMP rate limiting — some servers drop ICMP packets when receiving too many. Try TCP test instead.
• Firewall filtering — corporate or hosting firewalls sometimes drop ICMP entirely. The TCP fallback should still work.
• Genuine network issues — overloaded routers, faulty cables, ISP problems
• DDoS protection — services like Cloudflare may aggressively rate-limit echo packets

Our hosting environment doesn't allow PHP to execute the ping command, so we use a TCP socket connect as the next-best alternative. The TCP test connects to port 443 (HTTPS) on the target and measures how long the handshake takes. Functionally this answers the same questions ICMP would — is the server up, how fast does it respond, is there any loss — just through a slightly different mechanism.

If you specifically need ICMP results, run ping example.com from your own terminal / command prompt.

Screenshots are rendered by microlink.io, a free screenshot service with built-in ad-blocking and cookie banner dismissal. Your browser fetches the screenshot directly from their API — iWebVault never proxies the request.

Honest disclosure: microlink receives the URL being screenshotted as part of the request (their server has to load the page to render it). They may log this for service operation. We have no control over their logging policy.

iWebVault itself does not log the URL — we never touch the screenshot request server-side. If maximum privacy is required, take screenshots locally with a browser extension instead.

A few common reasons:

• Site blocks screenshot bots — some sites detect headless browsers and return blank pages or error pages
• Site requires login — paywalled or auth-walled content can't be captured anonymously
• JavaScript-heavy site — extreme cases may not fully render in the screenshot window
• Site is down — if ping also failed, screenshot will too
• HTTPS required — we always try https:// first; sites that only serve on http:// may fail
• Daily quota reached — our free tier allows 1500 screenshots/day across all visitors. If we hit the cap, screenshots pause until the daily reset.

Ping results change every second based on network conditions. We cache for 10 minutes (shorter than SSL's 24 hours) so shared links show recent data without being instant-stale.

For real-time monitoring, click "Ping again" to bypass cache. The rate limit (30 requests / hour / IP) still applies to refreshes.