DEV Community: Takeshi Hamaya

Never put a visitor's IP address in cached HTML

Takeshi Hamaya — Sat, 14 Nov 2026 03:46:47 +0000

Disclosure: I run BLST VPN Navi, a Japanese guide that answers worries about being watched, hacked, or cut off online, using official sources and daily price data. Some links on the site are affiliate links. This post is about how a small privacy widget works.

My site has a widget that shows what a page can see the moment you open it. It's for people who believe incognito mode hides everything. Showing their own values is faster than explaining.

Three lessons from building it.

1. Don't print the IP into the page

In PHP the visitor's IP is one variable away, so this is tempting:

// Don't do this
echo 'Your IP: ' . esc_html($_SERVER['REMOTE_ADDR']);

If the page is cached — by the server, a caching plugin, or a CDN — the first visitor's IP gets served to everyone after them.

You show strangers someone else's IP.
Each visitor thinks it's their own. Someone who just turned on a VPN may conclude it "didn't change" — or the opposite.

For a privacy tool, that's exactly backwards. And it looks fine when you test it yourself, so it's easy to miss.

Fix: leave a placeholder in the HTML and fetch the value from a separate endpoint that is never cached.

add_action('rest_api_init', function () {
    register_rest_route('blst/v1', '/whoami', [
        'methods' => 'GET',
        'callback' => 'blst_whoami',
        'permission_callback' => '__return_true',
    ]);
});

function blst_whoami() {
    $ip = blst_whoami_ip();
    $r = ['ip' => $ip] + blst_whoami_geo($ip);
    nocache_headers();   // per-visitor value
    return rest_ensure_response($r);
}

fetch('/wp-json/blst/v1/whoami', { credentials: 'omit' })
  .then(function (r) { return r.json(); })
  .then(function (d) { document.getElementById('ip').textContent = d.ip || '—'; });

Behind a proxy

Behind a reverse proxy or CDN, REMOTE_ADDR is the proxy. The client address arrives in headers like X-Forwarded-For:

function blst_whoami_ip() {
    foreach (['HTTP_CF_CONNECTING_IP', 'HTTP_X_REAL_IP', 'HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR'] as $k) {
        if (empty($_SERVER[$k])) continue;
        foreach (explode(',', $_SERVER[$k]) as $cand) {   // "client, proxy1, proxy2"
            $cand = trim($cand);
            if (filter_var($cand, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) return $cand;
        }
    }
    return $_SERVER['REMOTE_ADDR'] ?? null;
}

Visitors can set these headers to anything. For a widget that only shows people their own value, spoofing only fools the spoofer. For security decisions — login limits, rate limits — only trust these headers when the request comes through a proxy you control.

2. Don't call third-party IP services from the browser

I first called api.ipify.org from the browser. It's on standard ad-blocker lists, so for anyone running a blocker the request failed and the whole widget stayed empty. Privacy-minded readers — the audience — are the ones running blockers.

Serving the IP from my own domain fixed it.

3. Say honestly what leaves the browser

Country, city, and network owner are looked up server-side through an outside service (ipapi.co) and cached for a day so the same IP isn't queried repeatedly:

$key = 'blst_geo2_' . md5($ip);
// ...on a miss, ask ipapi.co, then:
set_transient($key, $out, $out['country'] ? DAY_IN_SECONDS : 10 * MINUTE_IN_SECONDS);

The note under the widget used to say it stored nothing and sent nothing anywhere. Rereading the code for this post, I realized that was wrong: the IP is sent to an outside service, and the lookup result is kept for a day. The note now says exactly that. A privacy tool that misdescribes its own data handling won't be trusted. I now reread that note whenever I change the code.

What the widget shows: 3 of 18 items can be hidden by a VPN

Group	Items	Count
Hidden by a VPN	IP address, approximate location, network owner	3
Not hidden by a VPN	device/OS, screen size, color depth, GPU, CPU count, memory, touch support, installed fonts, connection-speed hint	9
Reducible in settings	languages, time zone, cookies, Do Not Track, color-scheme preference, reduced-motion preference	6

A VPN hides 3 of the 18. The rest describe your device, and combined they can follow you across sites (fingerprinting).

I don't show "you are 1 in N" numbers. I have no population data to compare against, so I only state what can be counted.

Takeaways

Per-visitor values don't belong in cached HTML. Fetch them from an uncached endpoint.
Forwarding headers can be spoofed. Fine for display; not for security decisions.
Third-party calls from the browser get blocked — most often for the readers you care about.
Describe what you send and keep based on the code, and recheck it when the code changes.

My VPN leak test gave everyone 100/100. Here's how I rebuilt it

Takeshi Hamaya — Sat, 14 Nov 2026 03:45:13 +0000

Disclosure: I run BLST VPN Navi, a Japanese guide that answers worries about being watched, hacked, or cut off online, using official sources and daily price data. Some links on the site are affiliate links. This post is about how the test works.

My site had a "VPN leak test". While auditing it, I found that it gave every visitor 100 points, whether or not they used a VPN.

What was broken

The result function started with let score = 100 and never subtracted anything.
All three checks had empty failure branches.
When a request to an outside service threw, the code still stored status: 'success'.
The "DNS leak" check only compared the public IP returned by two services. It never looked at DNS.

So the test always said "safe". A security tool that gives false reassurance is worse than no tool: people keep using a leaking connection because they were told it's fine.

Rules for the rebuild

No score. A score needs weights (how much worse is a WebRTC leak than an IPv6 leak?). I can't justify those weights, so any score would be made up. The test now says only: leaking, not leaking, or can't tell.
If the browser can't measure it, say so. Never mark it as passed.
If an outside service is unreachable, say "can't tell". Never "safe".
Let people re-test right after fixing, and show what changed.

The baseline IP comes from my own server

First, get the IP the site sees. Everything is compared against it.

I used to call api.ipify.org directly from the browser. It turned out to be on standard ad-blocker lists. Readers who care about privacy are the ones running ad blockers — so the people I most wanted to reach were the ones whose test broke.

Now the baseline comes from a REST endpoint on my own domain, which blockers don't touch:

register_rest_route('blst/v1', '/whoami', [
    'methods' => 'GET',
    'callback' => 'blst_whoami',
    'permission_callback' => '__return_true',
]);

function blst_whoami() {
    $ip = blst_whoami_ip();
    $r = ['ip' => $ip] + blst_whoami_geo($ip);   // country, city, network owner
    nocache_headers();                            // per-visitor value: never cache
    return rest_ensure_response($r);
}

Country, city, and network owner are looked up server-side via an outside service (ipapi.co) and cached for one day.

Check 1: WebRTC

To find a direct route between browsers, WebRTC asks a STUN server for your public address. With some VPNs, that request goes around the tunnel and exposes your real IP.

var pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.createOffer().then(function (o) { return pc.setLocalDescription(o); });
pc.onicecandidate = function (e) {
  if (!e || !e.candidate || !e.candidate.candidate) return finish();
  var m = e.candidate.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}|(?:[a-f0-9]{0,4}:){2,}[a-f0-9]{0,4}/i);
  if (!m) return;
  var ip = m[0];
  // Private, link-local and CGNAT addresses are not leaks
  if (/^(10\.|127\.|169\.254\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|100\.(6[4-9]|[7-9][0-9]|1[01][0-9]|12[0-7])\.)/.test(ip)) return;
  if (/^(fe80:|fc|fd|::1$)/i.test(ip)) return;
  if (found.indexOf(ip) < 0) found.push(ip);
};

A leak means: a public address that differs from the one the server sees. Home LAN addresses don't count, and modern browsers usually hide them behind random .local names anyway.

Check 2: IPv6

If a VPN only tunnels IPv4, IPv6 traffic can flow outside it. I ask a dual-stack service (api64.ipify.org) which address I'm using:

fetch('https://api64.ipify.org?format=json', { cache: 'no-store' })
  .then(function (r) { return r.json(); })
  .then(function (d) {
    var ip = (d && d.ip) || '';
    if (ip.indexOf(':') < 0) return { state: 'ok' };    // IPv4 only
    if (ip === serverIp) return { state: 'ok' };         // IPv6, same route
    return { state: 'ng', ips: [ip] };                   // IPv6 outside the tunnel
  })
  .catch(function () {
    return { state: 'na' };   // unreachable: "can't tell", never "safe"
  });

That catch is the biggest difference from the old version, which reported success here.

If WebRTC and IPv6 find the same address (common when the device has a public IPv6), the result says it's one cause, not two.

Check 3: location vs. device settings

A VPN changes your IP, not your device. If you connect from abroad but your time zone is Asia/Tokyo and your language is ja, a site can infer you're in Japan using a foreign server. The test says plainly that a VPN can't hide this.

DNS leaks: "can't measure"

You can only see which DNS server resolved a name from the side that receives the query. JavaScript in a browser can't see it, and my site doesn't run that infrastructure. So the DNS row says the test can't be done in the browser and links to a dedicated site — instead of measuring something else and calling it "DNS: OK".

Results

State	Shown as
Leaking	red, with the address and the route
Not leaking	green
Can't tell	gray, with the reason

Even when nothing is found, it does not say "safe":

Within what this test can check, no leak was found. This does not mean you are safe.

It also shows the network owner. If it's your ISP rather than a VPN company, you're not on a VPN at all, and your IP is visible to every site you visit.

Re-test after fixing

The previous IP is kept in sessionStorage. On re-test, the page shows whether it changed — or warns that it didn't and the setting may not have applied. Results stay in the browser.

Takeaways

A security tool must not hand out unfounded scores or "you're safe".
If you can't justify the weights, don't make a score.
Say "can't measure" and "can't tell" out loud.
Serve the baseline IP from your own domain so ad blockers don't break it.

The rebuilt test (Japanese UI): https://www.blstweb.jp/network/vpn/leak-check/

Building a VPN Data Pipeline on Google Apps Script's Free Tier

Takeshi Hamaya — Sat, 20 Dec 2025 16:49:01 +0000

Correction (October 2026, updated November 2026): An earlier version of this article presented speed, stability, outage and price-change figures as results of "645+ measurements". Those figures were not real measurements and could not be verified, so I have removed them. The speed values were generated by measureVPNSpeed() (a fixed base value plus random numbers); that generator was retired in September 2026, and the speed values on my site are now my own estimates, not measured results. The code below is kept as it was written, so it still shows how the batch job ran. Correction notice for the dataset: https://doi.org/10.5281/zenodo.18423131 I also want to disclose that the site I run (BLST VPN Navi) earns affiliate commissions from some VPN providers.

TL;DR

I built a data pipeline on Google Apps Script that:

🔁 Runs a batch job for 15 VPN services every 6 hours
📊 Computes a stability score from the stored values (coefficient of variation)
🚨 Flags anomalies with a 3-sigma rule
💰 Keeps a price history and alerts on changes
🛡️ Ships a client-side DNS/WebRTC leak check tool
💵 Runs on Google Apps Script's free tier ($0/month)

Site: https://www.blstweb.jp/network/
GitHub: https://github.com/hmy0210/vpn-stability-ranking
License: MIT

Why I Built This

I run a Japanese guide for three online worries — being watched, being hacked, and not being able to connect abroad — that answers each one with official sources and daily price data, then points readers to a service that solves it. I wanted the numbers on the site (prices, server counts, scores) to update automatically instead of being typed by hand, and I wanted to see how far Google Apps Script's free tier could go as a scheduler, data store and API.

Architecture Overview

Google Apps Script (Orchestrator)
  ↓
┌─────────────────────────────────────┐
│  vpn-speed-tracker.gs               │
│  - Runs every 6 hours               │
│  - Processes 15 VPNs                │
│  - Calculates stability             │
└─────────────────────────────────────┘
  ↓
Google Spreadsheet (Data Store)
  - Speed data
  - Price history  
  - Outage logs
  - News archive
  ↓
Public Web App API
  - JSON endpoint
  - CORS enabled
  - No authentication needed

Why Google Apps Script?

✅ Free tier: 20,000 URL fetches/day
✅ Built-in triggers (time-based, event-based)
✅ Native Spreadsheet integration
✅ Deploy as Web App in one click
✅ No server maintenance

Core Feature 1: Speed Testing & Stability Scoring

The Problem with Averages

An average alone doesn't tell the full story: two series with the same average can vary very differently.

The Solution: Coefficient of Variation (CV)

I use CV to measure stability:

/**
 * Calculate stability score based on speed variation
 * Lower CV = More stable = Higher score
 */
function calculateStabilityScore(vpnName) {
  const sheet = SpreadsheetApp.openById(CONFIG.SPREADSHEET_ID)
    .getSheetByName('速度データ');

  const data = sheet.getDataRange().getValues();
  const recentSpeeds = data
    .filter(row => row[1] === vpnName)
    .slice(-10)  // Last 10 measurements
    .map(row => row[2]);  // Download speed

  if (recentSpeeds.length < 3) {
    return 50;  // Not enough data
  }

  // Calculate mean
  const avg = recentSpeeds.reduce((a, b) => a + b, 0) / recentSpeeds.length;

  // Calculate standard deviation
  const variance = recentSpeeds.reduce((sum, speed) => 
    sum + Math.pow(speed - avg, 2), 0) / recentSpeeds.length;
  const stdDev = Math.sqrt(variance);

  // Coefficient of Variation
  const cv = stdDev / avg;

  // Convert CV to 0-100 score
  // CV < 0.05 = 100 points (very stable)
  // CV > 0.3 = 0 points (unstable)
  const stabilityScore = Math.max(0, Math.min(100, 100 - (cv * 400)));

  return Math.round(stabilityScore);
}

Core Feature 2: Statistical Outage Detection

The Challenge

How do you automatically detect when a VPN is having issues?

The Solution: 3-Sigma Method

I use the 3-sigma rule (99.7% confidence interval):

/**
 * Detect outages using statistical analysis
 * Runs every hour via trigger
 */
function detectOutages() {
  const speedSheet = SpreadsheetApp.openById(CONFIG.SPREADSHEET_ID)
    .getSheetByName('速度データ');
  const outageSheet = SpreadsheetApp.openById(CONFIG.SPREADSHEET_ID)
    .getSheetByName('VPN障害検知（高度）');

  const data = speedSheet.getDataRange().getValues();
  const vpns = [...new Set(data.slice(1).map(row => row[1]))];

  vpns.forEach(vpnName => {
    const vpnData = data
      .filter(row => row[1] === vpnName)
      .slice(-20);  // Last 20 measurements

    if (vpnData.length < 10) return;  // Need at least 10 data points

    const speeds = vpnData.map(row => row[2]);
    const latest = speeds[speeds.length - 1];
    const historical = speeds.slice(0, -1);

    // Calculate mean and standard deviation
    const avg = historical.reduce((a, b) => a + b, 0) / historical.length;
    const stdDev = Math.sqrt(
      historical.reduce((sum, speed) => 
        sum + Math.pow(speed - avg, 2), 0) / historical.length
    );

    // 3-sigma threshold
    const threshold = avg - (3 * stdDev);

    if (latest < threshold) {
      const reason = `Speed anomaly detected: ${latest.toFixed(1)} Mbps ` +
                     `(avg: ${avg.toFixed(1)} Mbps, threshold: ${threshold.toFixed(1)} Mbps)`;

      // Check for consecutive anomalies
      const previousOutages = outageSheet.getDataRange().getValues()
        .filter(row => row[1] === vpnName)
        .slice(-5);

      const consecutiveCount = previousOutages.filter(row => 
        (new Date() - new Date(row[0])) < 3 * 60 * 60 * 1000  // Within 3 hours
      ).length + 1;

      // Log anomaly
      outageSheet.appendRow([
        new Date(),
        vpnName,
        latest,
        reason,
        consecutiveCount
      ]);

      // Alert if 3+ consecutive anomalies
      if (consecutiveCount >= 3) {
        sendAlert(`Outage detected: ${vpnName} - ${consecutiveCount} consecutive anomalies`);
      }
    }
  });
}

Core Feature 3: Price Monitoring

VPN prices change without notice, so the pipeline keeps a daily price history:

/**
 * Scrape VPN pricing daily
 * Uses ScraperAPI with fallback to direct scraping
 */
function scrapeAllVPNPrices() {
  const sheet = SpreadsheetApp.openById(CONFIG.SPREADSHEET_ID)
    .getSheetByName('VPN料金履歴');

  const vpnPricing = getVPNPricingConfig();

  vpnPricing.forEach(vpn => {
    try {
      let price = null;
      let method = 'direct';

      // Try ScraperAPI first
      if (SCRAPER_CONFIG.USE_SCRAPER_API && SCRAPER_CONFIG.API_KEY) {
        try {
          price = scrapeWithScraperAPI(vpn);
          method = 'scraperapi';
        } catch (error) {
          Logger.log(`ScraperAPI failed: ${vpn.name}`);
        }
      }

      // Fallback to direct scraping
      if (!price) {
        try {
          price = scrapeDirect(vpn);
        } catch (error) {
          price = vpn.defaultPrice;  // Use fallback price
        }
      }

      // Save to spreadsheet
      sheet.appendRow([
        new Date(),
        vpn.name,
        price,
        vpn.currency,
        method,
        !price ? true : false  // Fallback flag
      ]);

      Utilities.sleep(1000);  // Rate limiting

    } catch (error) {
      Logger.log(`Price scraping error: ${vpn.name} - ${error.message}`);
    }
  });
}

Core Feature 4: VPN Leak Detection Tool

100% client-side security diagnostics:

/**
 * DNS Leak Detection
 * Queries multiple DNS servers and compares IPs
 */
async function detectDNSLeak() {
  try {
    const responses = await Promise.all([
      fetch('https://api.ipify.org?format=json'),
      fetch('https://api.my-ip.io/ip.json')
    ]);

    const ips = await Promise.all(responses.map(r => r.json()));

    // All IPs should match if VPN is working
    if (ips.every((ip, i, arr) => ip.ip === arr[0].ip)) {
      return {
        status: 'success',
        message: 'No DNS leak detected - All servers report same IP',
        ip: ips[0].ip
      };
    } else {
      return {
        status: 'warning',
        message: 'Possible DNS leak - Different IPs detected',
        details: ips.map(ip => ip.ip).join(', ')
      };
    }
  } catch (error) {
    return {
      status: 'error',
      message: 'DNS leak check failed'
    };
  }
}

/**
 * WebRTC Leak Detection
 * Analyzes ICE candidates for real IP exposure
 */
async function detectWebRTCLeak() {
  return new Promise((resolve) => {
    const ips = [];

    const pc = new RTCPeerConnection({
      iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
    });

    pc.createDataChannel('');
    pc.createOffer().then(offer => pc.setLocalDescription(offer));

    pc.onicecandidate = (ice) => {
      if (!ice || !ice.candidate) {
        pc.close();

        if (ips.length === 0) {
          resolve({
            status: 'success',
            message: 'No WebRTC leak - Real IP not exposed'
          });
        } else {
          resolve({
            status: 'warning',
            message: `Private IPs detected (${ips.length})`,
            details: ips.join(', ')
          });
        }
        return;
      }

      // Extract IP from ICE candidate
      const ipMatch = /([0-9]{1,3}\.){3}[0-9]{1,3}/.exec(ice.candidate.candidate);
      if (ipMatch && !ips.includes(ipMatch[0])) {
        ips.push(ipMatch[0]);
      }
    };

    setTimeout(() => {
      pc.close();
      resolve({ status: 'success', message: 'No leak detected' });
    }, 3000);
  });
}

Try it live: https://www.blstweb.jp/network/vpn/leak-check/

Public API

All data is available via REST API:

curl https://script.google.com/macros/s/YOUR_ID/exec

Example response (illustrative values, not measurements):

{
  "status": "success",
  "timestamp": "2025-12-21T10:00:00.000Z",
  "totalVPNs": 15,
  "rankings": [
    {
      "timestamp": "2025-12-21T09:00:00.000Z",
      "vpnName": "ExampleVPN",
      "download": 460,
      "upload": 230,
      "ping": 15,
      "stability": 95.2,
      "reliability": 100,
      "totalScore": 97.8,
      "rank": 1
    }
  ]
}

Use cases:

Embed rankings in your blog
Research & analysis
Build your own VPN comparison tool

Cost Breakdown

Total monthly cost: $0

Component	Service	Cost
Automation	Google Apps Script	Free
Data Storage	Google Spreadsheet	Free
Web App API	Apps Script Web App	Free
Price Scraping	ScraperAPI (optional)	$0-29
Twitter Posting	Twitter API (optional)	Free

Google Apps Script Free Tier:

20,000 URL Fetch calls/day
6 hours execution time/day
30 MB script size limit

Perfect for this use case!

Setup Guide (5 Minutes)

1. Clone Repository

git clone https://github.com/yourusername/vpn-stability-ranking.git
cd vpn-stability-ranking

2. Create Google Spreadsheet

Create sheets:

速度データ (Speed Data)
VPN料金履歴 (Price History)
VPN障害検知（高度） (Outage Detection)
VPNニュース履歴 (News History)

3. Set Up Apps Script

Extensions → Apps Script
Copy files from gas/ folder
Edit config.gs:

const CONFIG = {
  SPREADSHEET_ID: 'your-spreadsheet-id',
  TIMEZONE: 'Asia/Tokyo'
};

4. Deploy as Web App

Deploy → New deployment
Type: Web app
Execute as: Me
Who has access: Anyone
Deploy

5. Set Triggers

measureAllVPNSpeeds: Every 6 hours
scrapeAllVPNPrices: Daily at 9am
detectOutages: Every hour
checkPriceChanges: Daily at 10am

Done! Your system is now running.

Lessons Learned

1. Statistical Methods > Simple Averages

Using CV and 3-sigma method revealed patterns I couldn't see with averages alone.

2. Automation is Essential

Updating prices and scores by hand doesn't scale. Scheduled jobs keep the data current.

3. Be Clear About What the Numbers Are

Say where each number comes from (official pages, estimates, or measurements) and disclose affiliate relationships. I learned this the hard way — see the correction at the top.

4. Free Tier is Powerful

Google Apps Script's free tier is incredibly generous. Perfect for side projects.

Contributing

This is a community project! Contributions welcome:

🐛 Report bugs: GitHub Issues
💡 Suggest features: GitHub Discussions
🔧 Submit PRs: See CONTRIBUTING.md
📖 Improve docs: Help translate
💬 Share feedback: X @takechiyo0210

Good first issues available!

Conclusion

Building this system taught me:

Statistical methods (CV, 3-sigma) are easy to implement in Apps Script
Scheduled automation keeps data current at no cost
Be explicit about where every number comes from

All code is open source. Fork it, improve it, use it!

📚 Japanese Version

Zenn: Google Apps Scriptで本番レベルのバッチ処理を実装する

VPN data pipeline on Google Apps Script - MIT License - GitHub

Have questions? Comment below or open an issue on GitHub!

DEV Community: Takeshi Hamaya

Never put a visitor's IP address in cached HTML

1. Don't print the IP into the page

Behind a proxy

2. Don't call third-party IP services from the browser

3. Say honestly what leaves the browser

What the widget shows: 3 of 18 items can be hidden by a VPN

Takeaways

My VPN leak test gave everyone 100/100. Here's how I rebuilt it

What was broken

Rules for the rebuild

The baseline IP comes from my own server

Check 1: WebRTC

Check 2: IPv6

Check 3: location vs. device settings

DNS leaks: "can't measure"

Results

Re-test after fixing

Takeaways

Building a VPN Data Pipeline on Google Apps Script's Free Tier

TL;DR

Why I Built This

Architecture Overview

Core Feature 1: Speed Testing & Stability Scoring

The Problem with Averages

The Solution: Coefficient of Variation (CV)

Core Feature 2: Statistical Outage Detection

The Challenge

The Solution: 3-Sigma Method

Core Feature 3: Price Monitoring

Core Feature 4: VPN Leak Detection Tool

Public API

Cost Breakdown

Setup Guide (5 Minutes)

1. Clone Repository

2. Create Google Spreadsheet

3. Set Up Apps Script

4. Deploy as Web App

5. Set Triggers

Lessons Learned

1. Statistical Methods > Simple Averages

2. Automation is Essential

3. Be Clear About What the Numbers Are

4. Free Tier is Powerful

Contributing

Links

Conclusion

📚 Japanese Version