What Is My IP Address Right Now?

Your public IP is the address websites and APIs see when you make a request. It belongs to your ISP — or to the proxy server, if you route through one — and it is what receives the response. The widget at the top of this page shows it for both protocol versions: IPv4 (32-bit, written like 203.0.113.42) and IPv6 (128-bit, written like 2001:db8::1). On a dual-stack network you will usually see both, because your OS picks one per destination. The local IP your router assigns inside your network (10.x or 192.168.x) is different and never appears here.

IPv4 uses 32-bit addresses — about 4.3 billion possible combinations, exhausted years ago. IPv6 uses 128-bit addresses, an effectively unlimited pool that ended the scarcity problem. Both are still in use side by side. Most modern devices and ISPs run dual-stack: you get one IPv4 and one IPv6, and the OS picks per request (usually IPv6 first). For proxy buyers this matters because IPv6 pools are larger and cheaper, but a sizable share of websites is still IPv4-only, so coverage depends on the target. For a deeper breakdown, see /en/ipv6-vs-ipv4.

From any shell with curl: run curl https://ip64.dcproxy.com to get plain text, or curl https://ip64.dcproxy.com/json for a JSON object with an ip field. Force a single protocol with curl https://ip4.dcproxy.com/json (IPv4 only) or curl https://ip6.dcproxy.com/json (IPv6 only). When checking through a proxy, prepend -x socks5h://USER:PASS@proxy.dcproxy.com:PORT — the socks5h scheme delegates DNS to the proxy and avoids local resolution leaks. Full Python, Node.js, and browser-side examples live in the code block above.

Run the same curl command twice — once direct, once with -x socks5h://USER:PASS@proxy.dcproxy.com:PORT — and compare the two responses. If both return the same IP, your proxy is not engaging at all. If the proxied response shows an IP from your DCPROXY range and the direct one shows your home address, the proxy is working end-to-end. If the IPs differ but neither matches DCPROXY, the proxy chain has a misconfiguration. The 4-step procedure above walks through the diagnostic in detail, including the SOCKS5 vs SOCKS5h trap.

It means your current network or ISP has no IPv6 connectivity, or IPv6 is disabled on the device. This is still common on home internet, older corporate networks, and some mobile carriers. The ip64.dcproxy.com endpoint will fall back to IPv4 in that case — you will see the IPv4 address in the widget instead of an empty IPv6 row. If you specifically need to test against IPv6-only targets, you will need either a network that routes IPv6 or a proxy that does, such as a DCPROXY IPv6 plan.

Most IP-detection services return whichever IP the connection happened to use, with no way to force a protocol. Our endpoints expose three distinct entry points — ip4 (A-only), ip6 (AAAA-only), ip64 (both) — so you can pin the protocol and prove which family is actually carrying your traffic. The JSON shape is identical across all three, so a script can swap URLs without changing its parser. That makes the endpoints far more useful for debugging proxy configurations and dual-stack networking than a single-URL tool.

Almost always a DNS or scope mismatch. The most common cause is using socks5:// instead of socks5h:// — plain SOCKS5 resolves hostnames locally before passing the connection through, which leaks your real IP via the DNS query. Switch to socks5h:// to delegate resolution to the proxy. Other suspects: a NO_PROXY environment variable excluding the test host, an application-level rule bypassing the proxy for some destinations, or browser connections that were established before you added the proxy and are still being reused. Restart the client after any config change.