DEV Community: gray sally

Is Your Network Really IPv6-Ready? Check in 10 Seconds

gray sally — Wed, 30 Sep 2026 00:57:22 +0000

IPv4 addresses ran out years ago. Most of us are now behind carrier-grade NAT (CGNAT) without even knowing it — which quietly breaks self-hosting, P2P connections, game servers, and direct remote access to your NAS.

So here's a simple question: does your network actually support IPv6 right now?

What the test checks

I built a free tool that answers this instantly: https://17nas.com/ipv6-test.php?lang=en-US

Open it and you immediately get:

Your IPv4 and IPv6 addresses (if you have one — many people discover they don't)
Dual-stack status — whether your connection can use both protocols
Latency to the test endpoints
ISP / network info attached to your addresses

No sign-up, no install. It runs entirely in the browser.

Why developers should care

Self-hosting: no IPv6 and no public IPv4 means you're stuck with relay tunnels or port-forwarding hacks.
WebRTC / P2P: works dramatically better with real end-to-end connectivity.
Debugging user reports: "it works on my machine" is often a v4/v6 difference between networks.

How it works

The page fetches a tiny asset over IPv4 and IPv6 in parallel from dual-stack endpoints. Whichever succeeds tells you what your network can actually reach — not what your ISP's marketing page claims.

If the test shows no IPv6 address, it's worth asking your ISP when they plan to enable it. And if you're on CGNAT with no public IPv4 either, that's useful to know before you spend a weekend trying to expose a home server.

Disclosure: I built this free tool. It's part of 17NAS, a small collection of free network utilities (the same site also has a NAT type test and a browser/IP timezone checker).

Your browser timezone and your IP timezone are two different answers

gray sally — Tue, 29 Sep 2026 20:32:59 +0000

Have you ever called Intl.DateTimeFormat().resolvedOptions().timeZone in your browser, compared it with an IP-geolocation-based "my timezone" result, and gotten two different answers?

Neither answer is wrong. They answer two different questions. Here is how they differ, why a mismatch is usually normal, and why a bare UTC offset is never enough to define a timezone.

Your browser timezone: what your OS claims

When JavaScript asks for your time zone, it doesn't ask the network — it asks the operating system:

const { timeZone } = Intl.DateTimeFormat().resolvedOptions();
console.log(timeZone); // e.g. "Asia/Shanghai"

Intl.DateTimeFormat().resolvedOptions().timeZone returns an IANA time zone identifier (like Asia/Shanghai, America/New_York, or Europe/Berlin) taken from the OS settings. It is free, instant, and privacy-friendly — but only as accurate as the machine's own configuration.

Your IP timezone: what your exit IP suggests

An "IP timezone" is estimated from your egress IP address via a GeoIP database. It answers a completely different question: where does the internet think your connection comes out?

These two can legitimately disagree:

VPN / proxy / corporate egress — your browser reports Asia/Taipei, but your traffic exits in Frankfurt, so the IP-based estimate says Europe/Berlin.
Remote desktop / cloud VM — the OS belongs to a machine on another continent.
Manually changed system timezone — developers do this all the time to test scheduling logic.
Stale or coarse GeoIP data — IP-to-location mappings are estimates, and they shift.

So when the two answers differ, it is not necessarily a bug on either side. It is a signal worth understanding — especially if your app relies on it for scheduling, logging, or analytics.

UTC offset ≠ time zone identifier

This is the part that bites developers most often. An offset like "UTC+8" is a snapshot, not an identity. "How many hours apart are two time zones?" is a question that only makes sense with a date attached, because daylight saving time shifts offsets through the year.

Take America/New_York: it is UTC-5 in January and UTC-4 in July. Hard-coding -5 will be wrong for half the year.

And the three-letter abbreviations are a trap. CST can mean at least three different things:

China Standard Time — UTC+8, no DST, all year
US Central Standard Time — UTC-6, switching to CDT (UTC-5) in summer
Cuba Standard Time — UTC-5, with its own DST rules

"PST" is no better (US Pacific vs. Philippine Standard Time, which is UTC+8 and observes no DST). Always use IANA identifiers like Asia/Shanghai or America/Chicago in code, APIs, and databases — never bare abbreviations.

A free tool that makes all of this visible

I came across a free timezone tool that puts these concepts into practice. Everything is computed locally in the browser — no location permission prompts, no data uploaded:

Timezone Detector & Converter

What it does:

Browser timezone, instantly — shows the IANA identifier your browser reports, the current UTC offset, and whether DST is active.
IP timezone, one click — estimates your timezone from your egress IP and puts it side-by-side with the browser timezone (it never displays your IP address). Great for a quick VPN egress check.
Time difference calculator — pick any two IANA time zones and get the offset for today, mid-January, and mid-July, with DST handled automatically. The "bring a date, not just an offset" principle, built in.
China reference table — China vs. Germany, Japan, New York, Los Angeles, the UK, France, Toronto, and Sydney at a glance.
Timezone knowledge FAQ — UTC vs. GMT, ambiguous abbreviations (CST/PST), why China uses a single legal time zone, and the story of Xinjiang's Ürümqi time.

Takeaways

Intl.DateTimeFormat().resolvedOptions().timeZone is your OS's answer; IP geolocation is your network's answer. Expect them to differ sometimes.
Offsets need dates. Use IANA identifiers, not "UTC+8" or "CST".
When in doubt, open the tool above and compare: browser time, the IP-based estimate, and the DST-aware difference calculator.

I built a CoreMark leaderboard for 100+ NAS CPUs — here's what the data actually shows

gray sally — Mon, 28 Sep 2026 14:57:15 +0000

Picking a CPU for a NAS or homelab server is mostly guesswork. Vendor spec sheets tell you core counts and boost clocks, but they don't tell you how an i3-12100T actually compares to a Ryzen 7 8840U for the kind of always-on, mixed workloads a home server runs. So I started collecting real CoreMark scores from real devices and put them on a public leaderboard: 17NAS.

Every score is submitted by a device owner and human-reviewed before it lands on the chart. Here's what a few hundred submissions taught me.

The top isn't who you'd expect

The current leader is the AMD EPYC 7513 (32C/64T) at 1,140,363, followed by the EPYC 7532 at 1,024,710. No surprise there — server silicon wins raw throughput. But scroll down and it gets interesting.

Efficiency is the real homelab story

Nobody runs a 280W EPYC in their closet. The interesting rows are the low-TDP parts:

Ryzen 7 8840U (8C/16T, ~28W): 379,594 — beats a desktop i5-11500 (267,917) while sipping power
i5-13500TE (35W): 436,649 — the "T tax" barely dents it
i3-12100T (35W): 175,087 — for a pure file server, this is all you need

If you're building today, the used-market sweet spot is last-gen mobile/handheld silicon, not old Xeons. A Xeon E5-2650 v4 still scores a respectable 584,273, but at 105W TDP and DDR4 platform costs, the efficiency math rarely works out anymore.

ARM is knocking

The Apple M4 (ARMv9, 4P+6E) sits at 292,013 — roughly matching a desktop i9-13900H-class part in this benchmark. And the Snapdragon 8 Elite Gen 5 shows up at 177,452. Neither is a NAS chip today, but the trajectory is obvious: ARM efficiency is coming for the low-power server segment, and it's worth watching.

Why CoreMark and not Geekbench?

CoreMark is small, deterministic, and runs on everything from a router SoC to an EPYC — which matters when your dataset spans x86, ARM, and whatever people have lying around. It's not a perfect proxy for NAS workloads (no I/O component), but as a pure CPU comparison across architectures, it's the most apples-to-apples number available.

The tools around it

The leaderboard is the core, but I also built two browser-based network tools that homelab folks keep asking for:

IPv6 connectivity test — checks whether your network actually has working v6, not just what your ISP claims
NAT type detection — figures out your NAT behavior, which matters if you're trying to reach your NAS remotely

Both run entirely in the browser, no signup.

Run your own and submit

If you have a NAS, mini PC, or old server, run CoreMark and submit your score — the chart gets more useful with every submission, especially for the oddball ARM boards and mini-PC chips that reviewers never benchmark.