DEV Community: ricco020

Leaving Vercel with a static site: the redirects you lose without noticing

ricco020 — Wed, 07 Oct 2026 11:48:32 +0000

This week I moved four static Astro sites off Vercel and onto a plain container host. The builds were the easy part: npm run build, copy dist/ into a web server image, done. What almost went wrong is everything Vercel had been doing around the build without my thinking about it.

The failure that does not show up

A static site on Vercel is not only a folder of HTML. vercel.json holds redirects, headers, cleanUrls and trailingSlash, and the platform applies them at the edge. Copy the same dist/ behind a default file server and:

the home page answers 200,
the build is green,
the deployment is marked healthy,
and every inherited 301, every /go/... short link and every extensionless URL returns 404.

Nothing reports it. No build step knows those rules existed. You find out weeks later in Search Console, or you never do. Between them the four sites carry 64 redirects, most inherited from older URL structures, plus header rules. Retyping them by hand is how one gets dropped.

What had to be rebuilt in the web server

I went with Caddy, and ended up translating five things:

Redirects, in file order. Vercel evaluates them top to bottom, so the Caddyfile wraps them in a route block to keep that order. Patterns like /old/:slug and /docs/:path* become path_regexp matchers, and :slug or $1 in the destination become capture group placeholders.
Host conditions. has: [{ "type": "host", "value": "www.example.com" }] becomes a host matcher on the same rule.
Headers. The catch-all /(.*) block becomes one global header directive, path-specific ones get a named matcher.
cleanUrls and trailingSlash: false. A redirect from /page.html to /page, a redirect away from the trailing slash, then try_files {path} {path}/index.html {path}.html.
Language negotiation on /. One site had a small middleware.ts sending visitors to /fr or /es from Accept-Language. In Caddy that is a header_regexp matcher and a 302, with Vary: Accept-Language and Cache-Control: no-store so no cache pins one visitor's language for everyone. Crawlers send no Accept-Language, so they keep the default root.

One detail I would not have guessed: short links. A rule on /go/docs does not match /go/docs/, and links copied around the web come in both forms. The generated matcher lists both.

Refuse, do not skip

The part I care most about is what the script does with a rule it cannot translate. rewrites, routes, missing, and has conditions other than host stop it with an error naming the rule. A warning would scroll past, and a skipped redirect is exactly the silent 404 the whole exercise is meant to avoid.

Two things that bit me anyway

npm ci failed in the container on one site because the lockfile had drifted from package.json. Vercel had been tolerating it. Decide whether you want to fix the lockfile or use npm install in the build stage, but find out before the cutover.
Verify on the served site, not the config. After each deploy I requested a sample of old URLs against the container's public address and checked the status code and the Location header. A Caddyfile that parses says nothing about whether your patterns mean what you think.

The script

It is one Python file, standard library only: it reads vercel.json and writes a Caddyfile, a two-stage Dockerfile (Node build, then caddy:2-alpine) and a .dockerignore.

python3 vercel-to-caddy.py <repo> --lang-root fr,es --out dist

Source, a worked example and the list of what is and is not handled: gitlab.com/ler.eric/vercel-to-caddy. It only covers static output; anything that needs functions or server rendering is out of scope.

I do this kind of migration and site work for clients at Z-AX. If you have a vercel.json pattern the script refuses, open an issue with the rule: the refusal list is where it should grow next.

80,000 Search Console impressions, zero clicks: three checks before you call it an opportunity

ricco020 — Wed, 07 Oct 2026 08:20:18 +0000

One of my sites went from about 850 Search Console impressions a day to 16,000 in a week. Before rewriting anything to "capture the opportunity", I spent ten minutes on the numbers. I am glad I did.

The numbers

Over 28 days the site showed 133,505 impressions. One page carried 88,640 of them: an article about what NordVPN really costs over 24 months. One query carried most of that page:

Query	Impressions	Clicks	Avg. position
nordvpn cost	80,721	0	9.0
nord vpn preis	6,729	0	2.6

Zero clicks at position 9 on eighty thousand impressions is unusual. Zero clicks at position 2.6 on nearly seven thousand is not something a human audience produces.

Three checks that took the "opportunity" apart

1. Compare with the site's own pages at the same rank. On the same property, in the same period, a French article at position 7.3 got 18 clicks from 985 impressions, and a Spanish one at 6.7 got 9 from 986. So the site does get clicks at these positions. This one query does not.

2. Look at who is supposedly searching. The property's top countries by impressions were Austria (18,895, 0 clicks), Denmark, the United States, Norway and the Netherlands. For an English page about a price in euros, Austria and Norway leading with no clicks at all is not a reader profile. 83% of impressions were on desktop, while clicks were split almost evenly between desktop and mobile.

3. Look at the shape over time. Daily impressions sat around 800, jumped to 4,953 on 24 September, stayed between 9,000 and 16,700 for six days, then dropped to 2,579 on 1 October. Demand for a product price does not behave like that. A scheduled job does.

I cannot prove what generated those impressions. Rank trackers and scrapers querying Google at scale are the obvious candidates, and Search Console counts an impression whenever the result is rendered in a results page, whoever asked.

What I changed

Nothing on the page. Its title already answers the query, and rewriting a title to chase readers who are not there risks losing the ones who are.

What I changed is the rule I work by: an impressions number is not a demand number until the clicks at that position look like the rest of the site. The check is cheap:

Take the page's query with the most impressions.
Find two other pages on the same property at a similar average position.
Compare click-through rates. An order of magnitude apart, with zero clicks, means the impressions are not people.
Split by country and device. If the split looks nothing like the pages that do get clicks, stop.

The dashboard total had told me this site was sitting on its biggest opening of the year. Excluding that single query, its impressions for the period were about 52,800, with the same 180 clicks. That is the number I plan with now.

Three of the eight sites that support /.well-known/change-password do not support it

ricco020 — Sun, 23 Aug 2026 22:31:06 +0000

There is a small W3C standard called A Well-Known URL for Changing Passwords. A site serves /.well-known/change-password, redirects it to its real change-password page, and password managers can send a user straight there instead of making them hunt through account settings.

I checked 24 well known sites for it tonight. The interesting part is not how many support it. It is that three of the eight apparent supporters do not support it at all, and the specification predicted exactly that.

The trap is written into the spec

A naive check is "does /.well-known/change-password return 200". That check is wrong, because plenty of servers return 200 for everything. A SPA with a catch-all route will happily serve its shell for any path you invent.

So the spec includes a countermeasure. Section 5 tells clients to also request a URL that should never exist:

/.well-known/resource-that-should-not-exist-whatever-forty-two

If that returns 200 too, the server is not answering your question. It is just saying 200 at everything. The support signal is void.

That is a rare thing to find in a standard: the authors anticipated the false positive and shipped the control with the feature.

What I measured

Two requests per host, one for the standard path and one for the control path, real HTTP, browser User-Agent, 24 hosts.

supports it for real   5 / 24     change-password 200, control 404
false positive         3 / 24     change-password 200, control 200
no support            16 / 24     404 (13), 403 (2), 400 (1)

Real support:

github.com        200 / 404
reddit.com        200 / 404
wordpress.com     200 / 404
apple.com         200 / 404
1password.com     200 / 404

False positives, which a 200-only check would have counted as wins:

twitter.com       200 / 200
netflix.com       200 / 200
linkedin.com      200 / 200

Without the control request I would have reported 8 supporters instead of 5. That is a 60 % overcount, from a check that never threw an error and looked green all the way down.

The part I did not expect

I included six password managers, since this standard exists mainly for their benefit. They are the consumers of the signal.

1password.com     supports it
bitwarden.com     404
dashlane.com      404
proton.me         404
lastpass.com      404
nordpass.com      404

One out of six serves the standard that password managers rely on. I am not going to pretend that is a scandal, these are marketing domains and the account systems often live elsewhere. But if you are building anything that touches password and passkey hygiene, it is a useful reminder that ecosystem support is thinner than the existence of a spec suggests.

If you want to add it

It is genuinely a two line change on most stacks. Redirect /.well-known/change-password to your existing change-password page with a 302, and make sure your 404 handler actually returns 404 for unknown paths under /.well-known/. That second half is the part people get wrong, and it is the half that makes the first half detectable.

The general lesson

I have spent a lot of this week finding checks that returned a confident answer to a question slightly different from the one I meant to ask. This is the same shape, with one difference: here the spec authors saw it coming and gave you the control request for free.

Most of the time nobody hands you the control. You have to think of it yourself, which usually means asking "what would this check return if the thing I am testing were completely absent?" If the answer is "the same thing", the check is decorative.

Google said it had never heard of my URL. The URL was fine, my probe was not.

ricco020 — Sun, 23 Aug 2026 22:23:06 +0000

Last night I ran Google's URL Inspection API against a site I run and got this back:

coverageState : 'Google ne reconnait pas cette URL'
lastCrawl     : JAMAIS

"Google has never heard of this URL." On a page that had been in the sitemap for weeks.

I was about to open a very large investigation. The page was fine. My probe was not. Here are the three ways that API lied to me in one sitting, and the one number that finally told me something true.

Trap 1: www and non-www are different URLs to this API

I passed https://save-my-disk.com/fr/blog/carte-sd-non-detectee. The sitemap declares https://www.save-my-disk.com/.... Same site to a human. Two different URLs to the API.

The result is not an error. It is not a 404. It is a confident, well-formed answer to a question I did not mean to ask:

without www :  'Google ne reconnait pas cette URL'   lastCrawl JAMAIS
with www    :  'Envoyee et indexee'                  lastCrawl 2026-07-18

The same page. Indexed the whole time.

The rule I now follow: never compose the URL you inspect. Read it out of the sitemap you actually serve. I fetch sitemap.xml, grep the slug, and inspect that exact string.

Trap 2: the `indexed` field on sitemaps is zero for everyone

The Sitemaps endpoint returns a contents block that looks like it answers the only question you care about:

{"type": "web", "submitted": 3258, "indexed": 0}

That indexed: 0 is not a measurement. I have a site doing 1677 impressions a month reporting indexed: 0. Every property I own reports indexed: 0. If you build a dashboard on that field you will build an alarm that fires forever.

Use errors and warnings from the same block. Those are real. Ignore indexed and inspect URLs individually if you want indexing state.

Trap 3: two states that read alike and mean opposite things

This is the one that matters, and it is the reason the whole exercise was worth it.

"Discovered - currently not indexed" means Googlebot knows the URL exists and has never fetched it. lastCrawl is empty.
"Crawled - currently not indexed" means Googlebot fetched the page, read it, and declined to index it. lastCrawl has a date.

They sit next to each other in the same report. They call for opposite work. The first is a crawl budget and discovery problem: more internal links, sitemap pings, authority. The second is a quality or duplication judgment: the page was seen and found wanting, and adding more pages like it makes things worse.

The number

I sampled 14 article URLs at random from a 590-page corpus on a data recovery site I run, and inspected each one. I validated the probe on a known-healthy control page first, which came back "Submitted and indexed" as expected.

 4/14   Submitted and indexed                      29 %
 4/14   Google does not recognise this URL     |
 4/14   Discovered - currently not indexed     |   8/14 with lastCrawl = never
 2/14   Crawled - currently not indexed            fetched, then declined

Eight of fourteen pages had never been fetched at all. Only two had been read and rejected.

I had spent the previous hour preparing to write another article for that site. The measurement says that would have produced a 657th URL that Googlebot has never visited. The bottleneck is not the writing. It is that two thirds of what already exists has never been looked at.

That reframes the work entirely: internal linking, sitemap hygiene and off-site authority, instead of publishing volume. Not a conclusion I wanted, which is usually a sign it is the real one.

What I would tell past me

Read the URL out of the artifact you serve. Do not build it from a folder name or a slug you remember.
Run any new probe against a page you already know is healthy, before you trust it on the page you are worried about.
When a check returns zero on everything it looks at, suspect the check first.

The API is not wrong in any of these cases. It answers precisely the question you asked. The gap between that question and the one you meant is where the hour goes.

Eight checks lied to me in one day, and none of them threw an error

ricco020 — Fri, 21 Aug 2026 15:11:19 +0000

In one working day I wrote or relied on eight checks that were wrong. Not one of them threw an
error. Every single one returned a plausible answer, which is exactly why each cost me time.

Here they are, with what they actually returned.

The four ways a check can lie

1. It never runs

I wrote assertions that validate prices against the strings shown to users, then deliberately
corrupted one to confirm the build would fail.

sabotaged price string
BUILD EXIT=0     <- the guard saw nothing

The assertions run on import. Nothing imported the module yet. After wiring it into a page that
is actually built, the same sabotage gave EXIT=1.

A check nothing calls protects nothing, and it is worse than no check, because you believe you
are covered.

2. It caches a stale verdict

A crawler wrote sitemap_absent: true on the first pass. I fixed the fetch, the data came back
correctly, and the report still printed "SITEMAP NOT SERVED" — because the flag was never
cleared.

The JSON on disk said 445 URLs. The screen said absent. I only caught it by opening the artefact
instead of reading the summary.

3. It asks for the wrong shape

Counting rendered questions on a page returned 0. I nearly reported that a paid feature shipped
nothing.

My selectors looked for DOM classes. The items were props of a client component, serialised into
the framework payload as {"q": …}. The page was 16,908 bytes in both measurements. The content
was always there; only my way of counting was wrong.

The fix was not a better guess. It was reading the type definition and counting what the code
actually emits.

4. It includes itself in its own sample

Two on the same day, and this is my favourite.

pgrep -af "next start"
# returns only the bash -c wrapper that contains the pattern

The old server was still holding the port under a different process name. I found it with
ss -ltnp — searching for who holds the port always works; searching for a name you assume it has
does not.

Then, checking whether a new slug collided with existing ones, I globbed the directory — including
the file I had just written. It saw itself and answered "already taken."

A probe that includes itself in its own sample always confirms what it is looking for.

The two failure modes, and why calibration is the whole job

A check can fail in exactly two directions, and I hit both:

too weak   counting accented characters       -> a text with a few accents passes while being wrong
too strong requiring a fixed list of words    -> cries on correct text that had no reason to use them

The German page was correct. My check demanded words the article never needed, and shouted anyway.

A false alarm that repeats gets ignored, and an ignored check protects nothing. That is the
quietest way to lose a safeguard: it stays in the code, it goes green in the reader's head, and it
stops saying anything.

The calibrated version turned out to be: a non-zero count of language-specific characters AND a
few witness words present — not all of them.

What I do now, and it costs three minutes

Test the guard by making it fail on purpose. Not once written, but every time it is written.
Sabotage the input, confirm it screams, restore. Two of my checks passed that test only on the second
attempt, and I would never have known otherwise.

Two other habits that came out of the same day:

Read the artefact, not the summary. The JSON, the manifest, the served HTML.
Prove identity, not just presence. "The server responds" is not "my version responds." A deployment I thought I was testing had never started; the old process answered 200 all along.

That last one is the same shape as a thing I ended up writing about elsewhere: a VPN kill switch
toggle being on tells you what the app intends, not what the operating system will do when the tunnel
dies at an awkward moment. I wrote up the four tests that actually settle it
here.

Eight wrong checks, zero errors raised. A check that crashes gets fixed. A check that answers
slightly the wrong question gets believed.

Two traps in the Bing Webmaster API that silently invert your site comparison

ricco020 — Fri, 21 Aug 2026 05:05:00 +0000

I spent a night comparing two sites in the Bing Webmaster API and reached three different
conclusions, each one demolishing the last. All three came from the same two traps. Neither raises
an error. Neither shows up in the JSON. Both silently invert the comparison.

Figures below are anonymised, because the ratios are the point, not whose sites they are.

Trap 1: `GetCrawlStats` history length is per site, and it is not the same

site A   76 data points   2026-06-05 .. 2026-08-19
site B    7 data points   2026-08-13 .. 2026-08-19

I wrote the obvious thing:

for p in data[:30]:
    total += p["CrawledPages"]

For site A that sums 30 days. For site B it sums 7, because there are only 7. No error, no
warning, just a number that is roughly a quarter of what I thought I was comparing.

My conclusion was "site B is crawled nine times less". Normalised per day, site B is crawled
more: 168 pages/day against 121.

The cause is that Bing does not backfill. A property verified last week has a week of history, not
a week of low activity. A short history looks exactly like a quiet site if you only read the
sum.

# what it should have been
per_day = sum(p["CrawledPages"] for p in data) / len(data)
window  = (min(dates), max(dates))   # and print it, always

Trap 2: `GetPageStats` covers a different date range per site, and never tells you

This one is worse, because there is no date parameter to get wrong. You call it, you get rows, each
row has a Date. I never looked at those dates.

site A   GetPageStats covers  2026-06-05 .. 2026-06-19    (15 days, in JUNE)
site B   GetPageStats covers  2026-08-14 .. 2026-08-14    (ONE day, in AUGUST)

I had been comparing June against August, fifteen days against one, and calling it a finding
about the sites. The whole analysis, and the follow-up work it justified, rested on that.

The check that caught it, and why it was written first

Before running any of this I had written down one rule:

If GetPageStats total impressions differ from GetRankAndTrafficStats over the same window, the
endpoint is sampling and the page counts are worthless. Stop there.

The measurement:

site A   PageStats 12 impressions   RankAndTraffic 10   ->  120 % coverage
site B   PageStats 714 impressions  RankAndTraffic 325  ->  220 % coverage

Two endpoints, same property, same window, and they do not agree with each other. So the check
fired and I stopped, instead of building one more conclusion on top.

Writing that rule down before measuring is the only reason I caught it. I had also written a
"reserve" in the earlier analysis, hedging that the average was fragile on a small sample. That
hedge was aimed at the right object for the wrong reason: the problem was never the average, it was
the window. A smart-sounding caveat can cover a defect without naming it, and reassure you into
keeping the wrong number.

What I would tell anyone using this API

Print the date range and the row count of every response before you compute anything. Not in debug mode. Always.
Never sum across sites without dividing by the number of points.
Cross-check two endpoints on the same window. If they disagree, neither is a total.
Write the invalidation condition before you measure, not after you like the result.

None of this is specific to Bing. GSC anonymises rare queries, so summing by query dimension covered
only 19 % of impressions on one of my properties, and comparing two sites that way reversed their
ranking. Same shape of error: an API answered exactly what I asked, and I had asked something
slightly different from what I meant.

The sites in the table are mine; one of them is VPNSmith,
where the traffic data came from. I am not going to publish their raw numbers, which is why the
ratios above are anonymised.

If you have a comparison in a dashboard right now that spans two properties, check that both sides
cover the same dates. Mine did not, for three hours, and it was confident the whole time.

Two thirds of VPN vendors ship no Content-Security-Policy. Including, sort of, us.

ricco020 — Thu, 20 Aug 2026 21:38:33 +0000

I scanned the public homepages of thirty commercial VPN vendors for the six HTTP response headers
that browsers actually act on. One GET each, 2026-08-20, 29 of 30 hosts answering.

mean score 3.66 / 6

Strict-Transport-Security   26/29   90%
X-Content-Type-Options      25/29   86%
X-Frame-Options             23/29   79%
Referrer-Policy             14/29   48%
Content-Security-Policy     10/29   34%   <-- the interesting one
Permissions-Policy           8/29   28%

Two out of three companies selling security do not ship a Content-Security-Policy.

Why that particular header

HSTS is one line in a config file and every hosting guide mentions it. That is why it is at 90%.

CSP is the one that costs real work, because writing a useful one means auditing every script the
marketing department has added over the years. It is the header that separates "we followed a
checklist" from "someone owns this".

Full scores (6/6): cryptostorm.is, mullvad.net, nordvpn.com, torguard.net, windscribe.com.
One vendor scored 0/6.

The part that makes this post worth writing

We are in the 34%, and our CSP is close to worthless.

script-src 'self' 'unsafe-inline' 'unsafe-eval' https:

Inline scripts allowed, eval allowed, script from any HTTPS host allowed. Against the injection
attacks a CSP exists to stop, that policy blocks very nearly nothing. We ship the header. We do not
ship the defence.

Which is the actual finding, and the reason it is printed on the dataset itself:

Presence is not correctness.

Ten vendors have a CSP. I did not check how many of those ten have a CSP worth having, because that
means reading each policy line by line. That work is not done, so the claim is not made.

Limits, stated up front

One observation, one moment. Headers change, sometimes weekly.
One vantage point. A CDN can inject or strip headers per edge node.
Homepage only. Checkout and account pages matter more and are not in this scan.
Presence, not correctness. As above. It is the main way to misread the whole table.

Reproduce it

The vendor list, the six header names and the scoring rule are published as a dataset under
DOI 10.5281/zenodo.22032840, so you can disagree with my
reading without taking my word for the numbers. Any HTTP client reproduces it in a few minutes, and
differences from this snapshot are expected and informative in themselves.

The longer write-up, including why a header scan tells you nothing at all about whether a VPN
service is trustworthy, is on VPNSmith.

If you run any public site: check your own script-src before you feel good about having a CSP. I
did, and that is how this post got its most useful paragraph.

GitHub says these three repos have no licence. They all do.

ricco020 — Thu, 20 Aug 2026 01:52:17 +0000

GitHub puts a licence label on every repository. It reads it from the LICENSE file and
normalises it to an SPDX identifier — MIT, BSD-3-Clause, Apache-2.0. When it cannot,
the API returns NOASSERTION and the web UI quietly says "Other".

I checked twelve popular proxy, VPN and mesh-networking repositories through the GitHub API
on 20 August 2026. Three came back NOASSERTION. Here is what each of the three actually
ships — because "Other" is not one situation, it is three very different ones.

The measurement

Repository	SPDX from the API	Stars
SagerNet/sing-box	NOASSERTION	37,141
XTLS/Xray-core	MPL-2.0	41,121
juanfont/headscale	BSD-3-Clause	43,009
tailscale/tailscale	BSD-3-Clause	35,368
v2fly/v2ray-core	MIT	34,491
wireguard/wireguard-go	MIT	4,347
apernet/hysteria	MIT	22,355
EAimTY/tuic	GPL-3.0	3,261
cloudflare/cloudflared	Apache-2.0	15,304
netbirdio/netbird	NOASSERTION	28,520
zerotier/ZeroTierOne	NOASSERTION	17,029
slackhq/nebula	MIT	17,630

Three out of twelve. Now the interesting part.

1. sing-box — GPLv3, plus a clause of its own

The LICENSE file opens with the standard GPL version 3 or later grant. Then it adds:

In addition, no derivative work may use the name or imply association with this
application without prior consent.

That sentence is why the label cannot be GPL-3.0: the text is no longer the unmodified
licence. The grant is still copyleft, with a naming restriction bolted on.

2. netbird — BSD-3-Clause, except where it is AGPLv3

Its LICENSE file says it plainly in the first two lines:

This BSD-3-Clause license applies to all parts of the repository except for the
directories [...] Those directories are licensed under the GNU Affero General Public
License version 3.0.

A permissive licence for most of the tree, and the strongest network copyleft there is for
part of it. One SPDX identifier cannot express that, and picking the friendlier of the two
is exactly the mistake the label would encourage.

3. ZeroTier — MPL, and a `nonfree/` directory

LICENSE.txt is three lines, and the second one is the one that matters:

See nonfree/LICENSE.md for all non-free ("source available") portions of this repository.

Source-available is not open source. A repository can be mostly MPL and still contain a
directory you may read but not freely reuse.

What to take from this

NOASSERTION does not mean "no licence" and it does not mean "unclear". It means GitHub
declined to summarise this one in a single word, and in all three cases it was right to
decline. An extra clause, a per-directory split, and a non-free carve-out are all things
that matter the moment you ship something built on top.

The practical rule is boring and holds up: if you are redistributing, open the LICENSE
file. The badge is a convenience, not a statement of terms. Two minutes of reading, and
the three repositories above stop being surprises.

I went down this road while comparing two of these cores in detail — the licence turned out
to be the sharpest difference between them, well ahead of the protocol lists everyone else
compares:
sing-box vs Xray: the differences that actually decide it.

All figures read from the GitHub REST API on 20 August 2026; star counts move, the licence
files are the stable part.

Your sysctl says one thing, the kernel says another

ricco020 — Wed, 19 Aug 2026 05:06:12 +0000

You set net.ipv4.ip_forward=1 in /etc/sysctl.conf. You rebooted. The value is still 0.

Nothing is broken, and you did not make a typo. On a host running UFW, there is a second sysctl file, and it wins.

Two files, one kernel

UFW ships /etc/ufw/sysctl.conf and loads it when the firewall comes up. It takes precedence over /etc/sysctl.conf. Anything you set in the familiar file that UFW also sets is quietly overwritten on the next ufw enable.

Quietly is the operative word. There is no warning, no log line, no diff. The file you edited still contains exactly what you typed — which is why this costs hours rather than minutes: you keep re-reading a correct file.

The symptom that most often brings people here: a WireGuard tunnel that comes up, a client that receives its address, and no traffic going anywhere. ip_forward fell back to 0.

Read the effective value, not the file

sysctl net.ipv4.ip_forward          # what the kernel applies
cat /proc/sys/net/ipv4/ip_forward   # same thing, one file

If that disagrees with what you wrote, look in /etc/ufw/sysctl.conf. Note the notation there uses slashes:

net/ipv4/ip_forward=1

Both net.ipv4.ip_forward and net/ipv4/ip_forward name the same knob. Grepping for only one of them is a good way to conclude the setting is absent when it is not.

A small script to stop guessing

I wrote a read-only checker that compares effective sysctl values against hardening recommendations and, more importantly, flags the ones that are declared somewhere and not applied:

 ECART  kernel.kptr_restrict            effectif=0      attendu=2
 ECART  fs.protected_hardlinks          effectif=0      attendu=1
         declare a 1 dans /etc/sysctl.conf, mais le noyau applique 0

That second line is the whole point. No dependencies, Python 3 only, changes nothing:
https://gitlab.com/ler.eric/sysctl-hardening-check

While we are here: what hardening does not cover

Tightening sysctl narrows what a compromised process reaches on that machine. It says nothing about the paths that never touch the machine — a password reused on a service that leaked, a session left open on a device you no longer carry, the one account that receives every recovery link.

That distinction is worth keeping in view: Linux hardening, what it covers and what it does not.

One line to keep: the file you edited is not necessarily the file that wins.

UFW and WireGuard: the tunnel is up and nothing goes through

ricco020 — Wed, 19 Aug 2026 03:37:35 +0000

The tunnel comes up. wg show prints a recent handshake. The client has its address inside the tunnel. And not a single byte reaches the internet.

Almost every guide answers this with "open UDP 51820 in the firewall". You already did that — it is why the handshake works at all. The problem is somewhere else, and UFW makes the distinction easy to miss:

Entering a machine and traversing it are two different permissions.

ufw allow 51820/udp lets packets arrive at the server. Your clients' traffic does not stop there — it goes through the box and out the public interface. That path lives in the FORWARD chain, which UFW denies by default and which no allow rule touches.

The four things to check, in order

1. IP forwarding — and the file that overwrites the other file

This is the one that costs hours, because the setting looks done.

UFW loads its own sysctl file at startup, and it takes precedence over the system one. A value you carefully set in /etc/sysctl.conf can be silently overwritten on the next ufw enable.

The right place is /etc/ufw/sysctl.conf:

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Then check the effective value, not the file you just edited:

sysctl net.ipv4.ip_forward

2. Forwarding, which is not the same as ingress

Targeted, and the one to prefer:

sudo ufw route allow in on wg0 out on eth0

Or globally, in /etc/default/ufw:

DEFAULT_FORWARD_POLICY="ACCEPT"

The second opens forwarding for every interface. It is a good ten-second diagnostic and a poor permanent configuration.

3. NAT, which UFW never adds on its own

Without it, packets leave carrying their tunnel address, which nothing on the internet knows how to answer. In /etc/ufw/before.rules, at the very top, before the *filter line:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Two classic mistakes here: putting this block after *filter (it is then ignored), and copying eth0 without checking.

4. The real name of the egress interface

eth0 is an article convention, not a fact. Depending on the host it will be ens3, enp1s0, something else. The command that answers without guessing:

ip route get 1.1.1.1

The test that separates the two families of causes

From a connected client, try to reach the server's address inside the tunnel (often 10.8.0.1):

What you observe	What it means
tunnel address answers, nothing external does	tunnel is fine — forwarding or NAT missing
tunnel address does not answer either	upstream: keys, `AllowedIPs`, client routing
everything answers but names do not resolve	not UFW at all — it is the DNS pushed to the client

That third row is worth knowing. "I have no internet" very often means "no name resolves". Pinging an IP directly tells you in one command.

After applying

before.rules is only re-read on reload:

sudo ufw disable && sudo ufw enable
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

One last thing that produces duplicate configurations: if your PostUp/PostDown rules in the WireGuard config already add MASQUERADE, you do not need the *nat block above. Both together rarely break anything, but they make the next outage much harder to read — and there will be a next one.

If you are still choosing a port or wondering whether 443/UDP is worth it, I wrote a longer piece on WireGuard ports, changing them and opening them properly.

One line to keep: an open port means packets can enter, not that they can traverse.

Your drive says SMART PASSED and is already failing: the 5 attributes that actually predict it

ricco020 — Sat, 15 Aug 2026 15:52:24 +0000

A drive that SMART calls PASSED can already be losing your data. The overall
self-assessment is a manufacturer threshold, not a statement about your files — and it stays
green well past the point where sectors have started going unreadable.

Here is the case that matters, from a real report:

SMART overall verdict : PASSED

Reallocated_Sector_Ct  = 24   sectors already remapped
Current_Pending_Sector = 8    sectors unreadable RIGHT NOW

That drive passes. It is also actively failing.

The five attributes worth reading

Forget the table of forty values. Five of them describe the two families that precede
unreadable data — reallocation and pending sectors:

ID	attribute	meaning
5	`Reallocated_Sector_Ct`	sectors already remapped
197	`Current_Pending_Sector`	unreadable now, waiting to be remapped
198	`Offline_Uncorrectable`	the drive could not read them offline
187	`Reported_Uncorrect`	errors it could not correct
188	`Command_Timeout`	commands that timed out

A non-zero 197 on a drive reporting PASSED is the exact situation to act on.

Read it in one command

smartctl -a -j /dev/sda | python3 smart_triage.py

The script is MIT, has no dependencies and no network access — it reads stdin and prints a
verdict, with exit codes 0 healthy, 1 monitor, 2 back up now, 3 stop and image:
https://gitlab.com/ler.eric/smart-triage

The order of operations, which decides whether you keep the data

If the verdict is stop and image, the sequence is not negotiable:

Stop using the drive. Every hour of use turns more pending sectors into lost ones.
Image the whole device to a file with ddrescue — not a file copy, a block-level image.
Work on the copy. Never on the original.

The mistake that destroys recoverable data is running a filesystem repair tool first. fsck
and chkdsk write to the disk. Writing to a drive with pending sectors is how a
recoverable image becomes an unrecoverable one — and it is irreversible.

What SMART does not tell you

SMART predicts a meaningful share of failures, not all of them. Controller failures, firmware
faults and head crashes can arrive with every attribute still green. A clean report is a reason
to keep monitoring, never a reason to skip backups.

If you want the detail of what is realistically recoverable per failure mode — mechanical,
electronic, logical, firmware — this breakdown covers it:
https://www.save-my-disk.com/en/blog/hard-drive-failure

A failed deployment is invisible from the web

ricco020 — Fri, 14 Aug 2026 06:27:43 +0000

Last night a deployment of mine failed for 21 hours and every monitoring check stayed green. The site answered 200 the whole time. Here is why that happens, and the two-line check that catches it.

The failure mode

When a build fails on Vercel (and on Railway, and on most platforms with atomic deploys), the platform does the sensible thing: it keeps serving the previous successful build. Your users see a working site. Your uptime monitor sees 200 OK. Your health check passes.

What nobody sees is that the commit you pushed is not the code being served. Every article, fix and config change since the last green build is sitting in git, live nowhere.

That is a good default — far better than serving a broken build. But it means "the site is up" and "my work is deployed" are two different questions, and most monitoring only answers the first.

The check that actually answers it

Compare the timestamp of your last commit with the timestamp of the last successful deployment. If the commit is newer by more than a build's duration, something is wrong:

git log -1 --format=%ct                 # last commit, unix time
npx vercel ls --prod                    # last deployments + their state

If the age of the newest Ready deployment is older than your last commit, you are serving stale code. In my case the newest Ready was 21 hours old, and two Error deployments sat above it.

The trap that cost me an hour

Here is the part worth the read. Outside a TTY, vercel ls splits its output across two streams:

stdout gets the deployment URLs, one per line — no status
stderr gets the formatted table, including the ● Ready / ● Error column

So this looks correct and silently returns nothing:

r = subprocess.run(["npx","vercel","ls","--prod"], capture_output=True, text=True)
errors = [l for l in r.stdout.splitlines() if "Error" in l]   # always empty

Your script reports zero errors on a project that is entirely broken. The fix is to read both streams:

out = (r.stdout or "") + (r.stderr or "")

The general lesson is worth more than the specific fix: an empty result and a clean result are not the same thing. If a check can return "nothing found" both when everything is fine and when the parsing broke, it will eventually lie to you — and it will lie in the reassuring direction. Make the two cases distinguishable:

if not lines:
    return "NOT VERIFIED"     # not "0 errors"

What actually broke the build

For the curious: a TypeScript error on a component prop. One call site out of 21 was missing a required id. Nothing exotic — but because the previous build kept serving, nothing surfaced it either.

I found the second occurrence only after the first fix failed, because I had listed the call sites with grep ... | head -8 on a file with 21 of them. A head on a search meant to be exhaustive turns "I saw nothing" into "there is nothing".

Three things to take away

Uptime monitoring does not detect failed deployments. Compare commit time to last successful deploy time.
Check the state of recent deployments, not just the age of the last good one.
When a check returns nothing, make sure it can tell you why — no data and no problem must not look identical.

If you are wiring up this kind of monitoring, the same reasoning applies to the telemetry you collect about it — what OpenTelemetry actually is, and what it deliberately does not give you covers the difference between producing telemetry and having observability, which is the trap one layer up.