IP Address

Purpose

Quickly show the public IP address and related diagnostics as seen by the server and the client’s browser. This tool combines a server-side endpoint (what the server sees for the request), a Cloudflare trace (public metadata), and browser local-network hints to help diagnose CDN, firewall, proxy, and connectivity issues. No data is stored unless you opt in.

🧭 What this feature shows

  • Server-side view — server time, REMOTE_ADDR, X-Forwarded-For, CF-Connecting-IP and other headers the server receives for your request.

  • Cloudflare trace (client) — parsed /cdn-cgi/trace response when fetched from the browser (public IP, colo, TLS, timestamp, etc.).

  • Cloudflare trace (server) — optionally fetchable from the server to compare what Cloudflare sees for server-side requests.

  • Local network (browser) — navigator.connection values (effectiveType, downlink, rtt) and full user agent.

  • Local LAN discovery — best-effort WebRTC trick to reveal local LAN IPs (modern browsers may return mDNS names or block this for privacy).

  • Live refresh — buttons to refresh server view and Cloudflare client trace without a full page reload.

👥 Who should use this

  • Developers debugging reverse-proxy / CDN / header / geo-routing issues.

  • Support staff investigating client vs server differences (e.g., CDN sending different IP or missing X-Forwarded-For).

  • Network administrators validating client connectivity and local network characteristics.

  • Shop owners who want to confirm the public IP and basic network diagnostics before sharing with support.

⚙️ How it works (high level)

  1. Server endpoint — the UI calls a server route (e.g., shopadmin.iptracker.server) which returns JSON of server-observed fields (time, remote addr, headers).

  2. Client Cloudflare probe — the browser attempts to GET https://www.cloudflare.com/cdn-cgi/trace to collect public IP and Cloudflare metadata; if blocked, the UI suggests fetching server-side Cloudflare trace instead.

  3. Local network hints — navigator.connection (where supported) provides browser-reported network parameters; the UA and platform are displayed.

  4. Local IP discovery — a WebRTC-based peer connection is created to surface ICE candidates; extracted IPv4/IPv6 addresses are shown if the browser permits them.

  5. Compare & triage — operators compare server-side and client-side results to identify proxies, header mismatches, CDN behaviour, or NAT issues.

🪜 How to use — step-by-step

  1. Open Dashboard → IP Tracker for the shop.

  2. Observe the Server-side block — server time and headers will be populated automatically.

  3. Click Refresh to re-query what the server currently sees (useful behind load balancers or after config changes).

  4. Click Fetch Cloudflare (server) if the client-side Cloudflare trace is blocked — the server will attempt to fetch /cdn-cgi/trace and return it.

  5. Click Refresh under Cloudflare Trace (client) to attempt a browser fetch of Cloudflare data.

  6. Click Discover local IPs to run the WebRTC discovery (best-effort).

  7. Share the results (copy/paste) with your developer or CDN provider when troubleshooting.

📊 How to interpret results

  • Client IP vs REMOTE_ADDR — If REMOTE_ADDR differs from the client IP or X-Forwarded-For, check your proxy/load-balancer configuration and ensure correct forwarding of headers.

  • CF-Connecting-IP — When Cloudflare is in front, CF-Connecting-IP should show the original client IP as seen by Cloudflare. If missing, verify Cloudflare settings and upstream header passthrough.

  • Cloudflare trace fields — ip, colo (datacenter), http, and tls help correlate geographic and transport behaviours.

  • Navigator hints — effectiveType, downlink, and rtt are approximate and may help explain slow or unstable connections but are not authoritative.

  • Local IP discovery — reveals LAN addresses (NAT/private RFC1918) if the browser allows; absence may mean the browser hides these for privacy.

✅ Recommended actions (prioritised)

  1. Header mismatch — if the server sees the proxy IP instead of client IP, enable/verify trusted proxy configuration and forwarding of X-Forwarded-For. In Laravel, configure TrustedProxy or App\Http\Middleware\TrustProxies.

  2. Cloudflare discrepancies — if Cloudflare trace on client differs from server, verify whether Cloudflare is proxying the server endpoint or if the server is behind a different CDN/proxy. Use the server-side Cloudflare fetch to compare.

  3. CORS / blocked client trace — if client-side /cdn-cgi/trace is blocked, use the server-side fetch and compare results. Consider sharing both with CDN support.

  4. Local network issues — if effectiveType shows 2g/3g unexpectedly, test connectivity and router configuration. Use the Internet Speed Test tool for quantitative measurements.

  5. Privacy-aware browsers — modern browsers may block or obfuscate local IPs (mDNS). Do not rely solely on WebRTC discovery for LAN IPs.

📤 Exporting & reporting

  • The UI is lightweight and intended for interactive diagnostics. Copy results from the page (or take a screenshot) to include in support tickets.

  • If you want persistent logs, implement an opt-in server endpoint that accepts the server/client payload and stores it with a timestamp and operator note (be mindful of privacy and obtain consent).

🔒 Privacy & safety notes

  • The feature deliberately does not store data by default. It only displays what the server and client already expose.

  • Cloudflare trace reveals the public IP address — treat it as operational data and avoid posting publicly without reason.

  • The WebRTC local-IP discovery may reveal private LAN addresses; do not collect or share these without consent. If you implement server-side logging, require explicit opt-in and retain for the minimal duration necessary.

🧩 Troubleshooting & FAQs

Q: CF-Connecting-IP is empty but Cloudflare is enabled. A: Ensure your origin server receives Cloudflare’s headers (check firewall rules or reverse proxy that might strip headers). Also confirm the request actually passed through Cloudflare (e.g., hostname proxied).

Q: Client Cloudflare trace fetch fails with CORS or network error. A: Some browsers or network policies block cross-origin calls; use “Fetch Cloudflare (server)” which fetches from the server side and returns the trace text.

Q: X-Forwarded-For contains multiple IPs — which is the client? A: The left-most (first) IP is typically the original client; subsequent entries are proxies the request passed through. Confirm your proxy chain & trusted proxy configuration.

Q: Local IP discovery shows mDNS names or no IPs. A: Modern browsers return mDNS hostnames or block direct local IP exposure for privacy. This is expected behaviour in many up-to-date browsers.

Q: Can this be logged automatically for audits? A: Yes — add an opt-in backend endpoint to capture snapshots. If you need that, implement secure auth, explicit consent, and data retention controls.

✅ Quick checklist

PreviousInternet Speed TestNextAvailability Check

Last updated