DEV Community: Michael Placzek

I Stopped Trying to Prove My Code Works. I Started Trying to Prove It Wrong.

Michael Placzek — Tue, 29 Sep 2026 13:15:00 +0000

For a long time, my tests asked a pretty normal question:

Does this code work?

Valid input goes in.

Expected output comes out.

Green checkmark.

Ship it.

Then I started building Network Doctor, an open-source network troubleshooting tool.

And that mindset stopped being good enough.

Because network software lives in the horrible little gaps between "valid" and "invalid."

An IPv6 address can be valid and still break your assumptions.

A simulated failure can look realistic while actually describing an impossible network.

A privacy filter can correctly redact 99% of addresses and still leak the one format you forgot existed.

A test suite can be completely green while the program is still wrong.

So I changed the question.

Instead of asking:

Can I prove this works?

I started asking:

How can I prove this is wrong?

That change has probably improved the project more than any individual feature I've added.

The happy path is the easy part

Network Doctor checks multiple layers of a connection:

network interfaces
DNS
TCP
TLS
HTTP
proxies
routing
path MTU

The normal cases are surprisingly boring.

DNS resolves.

TCP connects.

TLS negotiates.

HTTP returns a response.

The interesting bugs are hiding around the edges.

So I started deliberately feeding the project things I hoped would break it.

And they did.

IPv6 has been particularly good at humbling me

Take an address like this:

fe80::1%eth0

That %eth0 matters.

It identifies the interface scope for a link-local IPv6 address.

If you're writing code that parses, displays, compares, exports, or redacts network addresses, suddenly:

fe80::1

and:

fe80::1%eth0

are not necessarily interchangeable strings.

Then there are bracketed addresses:

[2001:db8::1]

And addresses embedded inside other text.

And equivalent IPv6 spellings.

And IPv6 addresses whose final group contains hexadecimal letters instead of looking suspiciously like an IPv4 address.

Each one is perfectly reasonable.

Each one is also an opportunity for a program to quietly make a bad assumption.

I have fixed multiple bugs in Network Doctor simply by asking:

What is the weirdest valid version of this input I can think of?

That question is becoming one of my favorite testing tools.

Then I started attacking the simulator

Network Doctor has a simulator because reproducing real network failures on demand is difficult.

I can describe situations like:

DNS is slow

or:

there is no default route

and exercise the diagnostic logic against them.

At first, I mostly tested whether valid scenarios worked.

Then I realized the simulator itself could lie.

What if a scenario claims there is no default route, but its other configuration requires one?

What if two simulated services try to listen on the same address?

What if a scheduled DNS delay is smaller than the simulator's timing precision?

What if a timeline contains latency values that cannot actually be represented correctly?

Those are not necessarily bugs in the diagnostic engine.

They are bugs in the laboratory used to test the diagnostic engine.

That is worse.

If your test environment can represent impossible states, a passing test can give you confidence in something that was never true in the first place.

So now the simulator gets attacked too.

My new rule: prove the bug before fixing the bug

This became especially important once I started using AI coding tools heavily.

AI is very good at looking at code and saying:

I found a bug.

Sometimes it really did.

Sometimes it found something that looked suspicious but was intentional.

Sometimes it misunderstood the surrounding code.

And sometimes it confidently proposed a fix for a problem that did not exist.

So I adopted a rule:

No proof, no fix.

The workflow looks roughly like this:

Find a suspicious behavior.
Reproduce it.
Write a test that fails because of it.
Confirm the failure is actually wrong.
Make the smallest reasonable change.
Run the regression test.
Run the rest of the test suite.
Try to break the new behavior again.

For Network Doctor that can include things like:

go test ./...
go test -race ./...
./scripts/check

along with fuzzing, cross-platform checks, simulator validation, and other project-specific tests.

The important part is not the commands.

The important part is the order.

The fix comes after the evidence.

A green checkmark does not mean "correct"

This sounds obvious.

But I think it is an incredibly easy trap to fall into.

A test suite only proves the things you asked it to prove.

If all your tests say:

Given normal input X,
does function Y return Z?

then congratulations.

You have learned a lot about normal input X.

Production is currently preparing input Q-17 from a Windows machine connected through a VPN with a scoped IPv6 address and a proxy configuration you have never seen before.

Good luck.

So I have been trying to make tests more adversarial.

Instead of only:

Does it accept valid input?

I want:

Which valid input looks invalid?

Instead of:

Does redaction work?

I want:

What representation of this address escapes redaction?

Instead of:

Does the simulator run this scenario?

I want:

Can I construct a scenario that should never be allowed to exist?

Those questions find much more interesting bugs.

Strangely, this has made AI more useful

I use Claude Code, Codex, and local models during development.

The more I use them, the less interested I am in whether they can generate lots of code.

Generating code is easy now.

Verification is the expensive part.

So one of the most useful things I can ask an AI coding agent is no longer:

Implement this feature.

It is:

Try to prove this implementation is wrong.

Look for counterexamples.

Find inputs that violate assumptions.

Trace the behavior through another platform.

Construct a regression test.

Compare what the documentation promises with what the code actually guarantees.

That turns AI from a code generator into something closer to an extremely persistent adversarial reviewer.

It still gets things wrong.

But that's fine.

Because it has to prove its case too.

This feels slower

Sometimes it is.

A tiny bug can become:

investigation
→ reproduction
→ regression test
→ fix
→ full validation

instead of:

change three lines
→ looks good
→ merge

But the second workflow only looks faster because it stops measuring time before the bug comes back.

I would rather spend an extra hour proving a fix today than spend a day figuring out why an "obvious" fix caused something bizarre three releases later.

I don't want tests that agree with me

I want tests that are annoying.

I want fuzzers discovering inputs I didn't consider.

I want the simulator refusing contradictory scenarios.

I want privacy tests assuming I forgot another representation of an IP address.

I want CI rejecting something that looked completely harmless.

I want another developer to look at my implementation and ask:

But what happens if...?

That sentence is incredibly valuable.

Software gets interesting exactly where our assumptions stop working.

So these days, when I finish a feature, I try not to ask:

Did I make this work?

I ask:

If I wanted to embarrass the person who wrote this, how would I break it?

Unfortunately, that person is usually me.

And so far, it has been a pretty effective development strategy.

Network Doctor is open source, and I am continuing to build it in public.

What is the weirdest edge case your tests have ever caught before a user did?

I genuinely want to hear them.

Combating AI Slop in Network Doctor

Michael Placzek — Fri, 25 Sep 2026 13:00:00 +0000

I use AI heavily while developing Network Doctor.

Claude Code, Codex, and local models have all helped me find bugs, write tests, investigate weird edge cases, review code, and improve documentation.

I am not interested in pretending otherwise.

But there is a problem.

AI can produce code that looks extremely convincing while being completely unnecessary, subtly wrong, overengineered, or based on a bug that never existed in the first place.

That is what is known as AI slop.

And as I have used AI more while building Network Doctor, I have become much more interested in a different question:

How do you get the speed of AI-assisted development without slowly filling your project with garbage?

I do not think the answer is "stop using AI."

I think the answer is to make the repository hostile to unverified work.

Rule 1: prove the bug exists

This is probably the most important rule in Network Doctor's repository guidelines:

Before changing behavior, verify the reported issue against the current HEAD.

That rule exists for humans, but it is especially useful for AI.

Give a coding agent a convincing bug report and it will often happily start fixing it.

That does not mean the bug is real.

Maybe the report is outdated.

Maybe another change already fixed it.

Maybe the reproduction depends on an assumption that is false.

Maybe the proposed fix is solving the wrong layer entirely.

So before I want a fix, I want evidence.

Reproduce it.

Write a focused test.

Show me the failure.

Then fix it.

A surprising number of "bugs" become much less convincing once you require that first step.

This also changes the way I prompt coding agents. Instead of:

Fix this bug.

I increasingly want something closer to:

Investigate this report against current HEAD. Do not change anything until you can reproduce it. If it is valid, create the smallest regression test that demonstrates the problem.

That one distinction removes a lot of garbage before it ever reaches the codebase.

Rule 2: AI does not get to declare itself correct

One of the easiest traps with coding agents is this:

AI writes the code.
AI reads the code.
AI says the code looks correct.
Done.

That is not verification.

Network Doctor has a local validation command:

./scripts/check

It runs formatting checks, go vet, builds the project with the same CGO_ENABLED=0 constraint used by releases, cross-compiles for multiple operating systems, and runs the ordinary Go test suite.

For changes where concurrency matters, there is also:

./scripts/check --race

CI goes considerably further.

There are integration tests, fuzz tests, security analysis, platform checks, packaging checks, documentation checks, and other repository invariants.

The important part is that these checks do not care how confident an AI model sounds.

The code either satisfies the contract or it does not.

Rule 3: turn important assumptions into executable rules

Documentation saying "please don't do this" is useful.

A test that fails when somebody does it is better.

Network Doctor has accumulated tests for things that would otherwise be very easy to accidentally break.

Some protect architecture.

Some protect packaging.

Some protect documentation.

Some protect stable behavior.

And one of my favorites is extremely small:

Network Doctor rejects em dashes in tracked text files.

There is an actual test for it.

Why?

Because I kept seeing them creep back into generated text, especially from AI-assisted writing. I did not want that style in the project, so instead of repeatedly asking models not to use them, I made the repository enforce the rule.

Now it does not matter whether the text came from me, Claude, Codex, a contributor, or something else.

If an em dash comes back, the test fails.

That is a tiny example, but the principle scales:

If you keep correcting the same AI mistake manually, consider turning the correction into an invariant.

The repository starts remembering the lesson for you.

Rule 4: protect the boring contracts

AI loves improving things.

Sometimes that is exactly the problem.

A mature CLI has behavior that should remain boring.

Argument shapes.

Exit codes.

JSON fields.

Labels.

Timeout behavior.

Platform boundaries.

Output semantics.

Once users or scripts depend on those things, an "improvement" can easily become a regression.

Network Doctor has tests around many of these contracts precisely because a locally reasonable change can have consequences somewhere completely different.

This matters even more with agents because they are very good at making a modification look internally consistent.

They can update the implementation, update the nearby test, update the comment, and produce a beautifully self-consistent change that still breaks the public contract.

The defense is having tests outside the immediate implementation that say:

No. This behavior belongs to the user now.

Rule 5: fuzz the places where cleverness gets dangerous

Some areas of Network Doctor deal with messy input:

targets and addresses
sanitization and redaction
DNS responses
generated network simulations

These are exactly the kinds of places where an AI-generated implementation can look elegant while missing one horrible input nobody thought about.

So Network Doctor fuzzes them.

For example, changes to target parsing have a dedicated fuzz target. Sanitization has one too.

I like fuzzing in an AI-heavy workflow because it changes the argument.

The model can tell me why its parser is correct.

I would rather throw thousands of ugly inputs at it.

Rule 6: replay reality

Unit tests are necessary, but networking has an annoying property:

Reality is much stranger than the test cases you invent.

Network Doctor has a field-case corpus containing recorded diagnostic situations. Its diagnosis engine can replay those snapshots without performing the original network probes.

That gives me another defense against plausible-looking changes.

A modification to diagnostic reasoning might pass the test the agent just wrote while changing how an old real-world incident is interpreted.

Replay catches that class of mistake.

This is something I want to expand over time.

Every strange real-world failure can become another permanent adversary for future code.

The project gets harder to fool.

Rule 7: use AI against AI

I also do not always use the same model for implementation and review.

Sometimes one agent investigates.

Another reviews the resulting diff.

Another looks specifically for edge cases.

Sometimes I use a local model.

Sometimes Claude Code or Codex catches something another model missed.

This is not because one model is magically trustworthy.

It is because disagreement is useful.

If one agent writes 200 lines and another immediately says, "This can be 30," that is worth investigating.

If one agent claims an edge case is impossible and another produces a reproduction, even better.

AI is very good at generating hypotheses.

So I try to use multiple passes to attack those hypotheses instead of treating the first answer as truth.

Rule 8: test the actual platforms

Network Doctor supports Linux, macOS, and Windows.

Cross-compilation catches a lot.

It does not catch everything.

So I also test releases on real machines.

That has included Fedora, Windows 11, and macOS systems.

This matters because AI knows what platform APIs usually do.

The machine gets the final vote.

Networking is especially good at exposing the difference between "this should work" and "this actually works."

Rule 9: keep changes small enough to understand

Another defense against slop is simple:

Do less at once.

When an AI agent produces a giant refactor, every additional changed behavior increases the amount of trust required to review it.

A focused change is much easier to challenge.

What was broken?

How was it reproduced?

What changed?

Which test proves it?

What unrelated behavior moved?

Ideally, the answer to the last question is "none."

I would much rather merge five boring changes that I understand than one spectacular AI-generated rewrite that requires faith.

The goal is not "AI-free" code

I sometimes see the AI coding discussion reduced to two positions:

AI writes everything now.

Real programmers do not use AI.

Neither is particularly useful to me.

I am building an open-source project largely by myself. AI lets me investigate more ideas, test more edge cases, review more code, and move faster than I otherwise could.

I absolutely want that leverage.

What I do not want is the corresponding temptation to lower the standard for what gets merged.

So I have slowly arrived at a different model:

AI can propose almost anything.

The repository decides what survives.

Reproduce first.

Test behavior instead of confidence.

Turn repeated mistakes into invariants.

Fuzz dangerous boundaries.

Replay real failures.

Cross-check with other models.

Run on real operating systems.

Keep the changes small.

And never confuse a very convincing explanation with evidence.

AI slop is not inevitable.

But preventing it takes more than writing "please produce high-quality code" in a prompt.

You have to build a development process that assumes plausible-looking garbage will occasionally appear, then make that garbage difficult to merge.

That is what I am trying to do with Network Doctor.

And somewhat ironically, AI has helped me build many of the defenses against AI itself.

Network Doctor is an open-source cross-platform network troubleshooting TUI written in Go. It diagnoses interface, DNS, TCP, TLS, HTTP, proxy, path-MTU, and other connectivity problems and tries to tell you where the failure actually is instead of dumping raw probe output.

GitHub: https://github.com/heymaikol/network-doctor

Website: https://networkdoctor.dev/

I spent months building an open-source network diagnostic tool. Now I’m trying to make my first dollar.

Michael Placzek — Sat, 19 Sep 2026 13:00:00 +0000

For the last few months, I've been building Network Doctor.

It's a cross-platform terminal application for answering a deceptively simple question:

Where is this connection actually breaking?

When something on the network fails, the normal troubleshooting process tends to look like this:

Run ping
Run dig
Try curl
Check the proxy
Try another DNS server
Run a traceroute
Check TLS
Try another network

Eventually, if you're experienced enough and collect enough evidence, you figure out whether the problem is your machine, your local network, DNS, the path, a proxy, or the service itself.

I wanted one tool that could reason across those layers instead of making the user interpret each command independently.

That became Network Doctor.

Today it runs on Linux, macOS, and Windows and checks things like:

interfaces and local connectivity
DNS
public and encrypted DNS
TCP
TLS
HTTP and HTTPS
proxies
routing
path MTU
service-specific connectivity

It also has Watch Mode for intermittent failures, diagnostic snapshots, remote diagnosis, two-sided diagnosis, service profiles, and a network simulator with deliberately broken networks.

I just released v1.17.3.

But this release also marks a different milestone for me.

The project has made $0

I've spent a lot of time building Network Doctor.

People use it. People star it. People contribute to it. It's available through package managers.

Other projects have even started pointing their own users toward it for network troubleshooting.

But financially, it has made me $0.

I don't want to turn the useful parts of Network Doctor into paid features just because I want the project to become sustainable.

So I'm trying something else.

Paid help, not a paid binary

Network Doctor can generate a sanitized support snapshot locally:


netdoc --support support.ndoc example.com

Looking for Contributors: Good First Issues in Network Doctor

Michael Placzek — Thu, 17 Sep 2026 05:02:39 +0000

I’ve been working on Network Doctor, an open-source Go TUI for diagnosing network problems, and I’d like to get more people involved in the project.

I currently have a few issues ready for contributors.

Good first issues

#110 - Make the causal-evidence golden mutation test non-vacuous

A small, test-focused issue. No production behavior changes are needed.

https://github.com/heymaikol/network-doctor/issues/110

#111 - Add hermetic tests for macOS and Windows SSID command wrappers

A slightly larger testing task involving the existing platform-specific SSID code.

https://github.com/heymaikol/network-doctor/issues/111

Looking for something more involved?

#97 - Bound hunt shard inputs before `netdoc-sim merge` decodes them

This one involves input-size enforcement and is better suited to someone already comfortable with Go.

https://github.com/heymaikol/network-doctor/issues/97

There are also several field-validation issues for contributors who have access to environments I can’t easily reproduce, including macOS, IPv6-only networks, VPN split DNS, captive portals, and managed proxy networks.

Network Doctor is here:

https://github.com/heymaikol/network-doctor

The contributor setup is intentionally simple:

git clone https://github.com/heymaikol/network-doctor.git
cd network-doctor
go test ./...
go run . github.com

If you’re new to open source, that’s completely fine. The good first issues are scoped so you shouldn’t need to understand the entire project before getting started.

Questions are welcome too.

Ping Works, but HTTPS Doesn't: How to Find What Actually Broke

Michael Placzek — Sun, 13 Sep 2026 13:00:00 +0000

You've probably seen this before:

$ ping example.com
64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=18 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=17 ms

So the network works, right?

Then:

$ curl https://example.com
curl: (28) Connection timed out

Or your browser spins forever.

This is one of the most common traps in network troubleshooting: treating a successful ping as proof that "the network is fine."

It isn't.

ping answers one fairly narrow question. Your application depends on several other things succeeding after that.

What ping actually proves

Ping normally uses ICMP echo requests and replies.

If a host responds, you've learned something useful:

your machine has some working route toward the destination
packets can travel across at least part of that path
the destination, or something representing it, is responding to ICMP

But an HTTPS connection needs much more.

A simplified path looks something like this:

Network interface
      |
Routing
      |
DNS
      |
TCP connection
      |
TLS handshake
      |
HTTP
      |
Application

And real networks can add more:

Proxy
VPN
Firewall
NAT
MTU problems
IPv4 / IPv6 differences

A successful ICMP echo doesn't prove all of those layers work.

That's why "but I can ping it" often doesn't get you very far.

DNS can still be the problem

There are a few variations here.

Suppose you run:

ping 1.1.1.1

and it works.

That says nothing about DNS.

Try:

dig example.com

or:

getent ahosts example.com

If name resolution fails, applications using hostnames will still be broken even though you have basic IP connectivity.

There's another wrinkle: your application and your diagnostic tool may not necessarily use DNS in exactly the same way.

Your system resolver, a browser using encrypted DNS, a VPN-provided resolver, and a corporate DNS setup can produce different behavior.

So "DNS works" can sometimes need a more specific question:

Which DNS, resolving what name, from which environment?

TCP can fail even when ping succeeds

HTTPS normally needs a TCP connection to port 443.

That is a completely different exchange from ICMP.

You can test it directly:

nc -vz example.com 443

or:

curl -v https://example.com/

A firewall might allow ICMP while blocking TCP 443.

The server might be reachable but not listening on the expected port.

A VPN route might send the application traffic somewhere different.

A proxy might be involved.

The path could simply behave differently for the traffic your application actually uses.

So this situation is perfectly possible:

ICMP       PASS
TCP :443   FAIL

There is no contradiction there.

You're testing two different things.

TCP working still doesn't prove HTTPS works

Let's say port 443 accepts a connection.

Great.

You're still not done.

Before HTTP can happen over HTTPS, the client and server need to complete a TLS handshake.

TLS can fail because of things like:

certificate validation
hostname mismatches
TLS interception
protocol incompatibility
a middlebox interfering with the connection
the wrong service running on the port

You can inspect that layer with tools such as:

openssl s_client -connect example.com:443 -servername example.com

or:

curl -v https://example.com/

At this point you can have:

DNS    PASS
TCP    PASS
TLS    FAIL

That is much more useful than saying "the internet is broken."

You now know roughly where to look.

And TLS working doesn't prove HTTP works

Suppose DNS resolves, TCP connects, and TLS completes.

The server can still return an HTTP error.

You might get:

403 Forbidden

or:

502 Bad Gateway

or:

503 Service Unavailable

That's a very different problem from a dead network path.

The connection reached the service.

The service responded.

The failure has moved farther up the stack.

That's why I like troubleshooting networking as a sequence of questions rather than one giant "does it work?" test.

Don't forget proxies

Proxies make this even more interesting.

Your shell might have:

HTTPS_PROXY=http://proxy.example:8080

while also having something like:

NO_PROXY=internal.example.com

Now two requests to different hosts may follow completely different paths.

One can go directly to the destination.

The other can go through a proxy.

If the proxy is down, misconfigured, or excluded incorrectly, the symptoms can look like an ordinary network failure even though the direct network path is perfectly healthy.

Testing both paths can matter.

For example:

curl -v https://example.com/

and, when appropriate:

curl --noproxy '*' -v https://example.com/

If one succeeds and the other doesn't, you've learned a lot.

Path MTU problems are another nasty case

Some failures are even stranger.

Small packets work.

Connections establish.

Then larger transfers hang or behave unpredictably.

This can happen when the effective MTU somewhere along the path is smaller than expected and Path MTU Discovery isn't working correctly.

That's one reason a simple ping can be especially misleading.

A tiny ICMP echo succeeding isn't proof that larger application traffic can make it through the same path successfully.

The useful question isn't "does the network work?"

A better question is:

What is the first layer that doesn't work?

Instead of:

Internet broken

you want to reach something more like:

Interface     PASS
DNS           PASS
TCP           PASS
TLS           FAIL
HTTP          SKIPPED

or:

Interface     PASS
DNS           FAIL
TCP           SKIPPED
TLS           SKIPPED
HTTP          SKIPPED

Those are very different problems.

And once you know which layer failed, the number of possible causes becomes much smaller.

Doing this manually

You absolutely can troubleshoot this with the standard tools.

Depending on the problem, I regularly reach for things like:

ip route
ping
dig
nc
curl
openssl
traceroute
mtr

Those tools are excellent.

The difficult part isn't usually running them.

It's deciding:

which test to run next
what its result actually proves
which later tests are meaningful after an earlier failure
whether two failures are related or independent

That is why I built Network Doctor.

The project is open source: Network Doctor on GitHub.

Instead of treating connectivity as one yes/no test, it probes the relevant layers independently and tries to identify where the evidence stops.

For example:

netdoc example.com

It can check things including the local interface, DNS, TCP, TLS, HTTP, proxy connectivity, and path MTU, then give you a diagnosis based on those results.

I still use the underlying tools when I need to dig deeper. Network Doctor isn't intended to replace curl, dig, mtr, or the rest.

The goal is to get to the right one faster.

The reverse is also true: ping can fail while everything works

There's another reason not to treat ping as the final authority.

Some networks and servers simply block or deprioritize ICMP.

You can see:

ping: no reply

while this works perfectly:

curl https://example.com/

From the application's perspective, that's not an outage.

The traffic you actually care about succeeded.

This is why good diagnostics need to test the protocol that matters instead of assuming ICMP represents every other kind of traffic.

A better troubleshooting habit

The next time you hear:

"It can't be the network. Ping works."

Ask what layer has actually been tested.

Work upward:

Do I have an interface and route?
        ↓
Can I resolve the name?
        ↓
Can I reach the service's port?
        ↓
Can I complete TLS?
        ↓
Can I make the application request?

If there is a VPN or proxy involved, test that path too.

The goal isn't to collect as much command output as possible.

The goal is to find the boundary between working and broken.

Once you know that boundary, network troubleshooting gets a lot less mysterious.

Debugging a Network Problem From Another Machine

Michael Placzek — Sat, 29 Aug 2026 13:00:00 +0000

One of the most useful questions in network troubleshooting is also one of the simplest:

Does it fail from another machine too?

If a website will not load on my laptop, trying it from another computer can immediately change the investigation.

If it works there, the service probably is not down. Something about my machine, DNS configuration, VPN, firewall, route, or network path is different.

If it fails there too, the problem may be farther upstream.

I wanted Network Doctor to be able to ask that question directly.

So I added remote diagnosis over SSH.

netdoc --via ideapad github.com

Instead of running the diagnosis locally, Network Doctor connects to ideapad, runs the checks there, and reports the result back on my machine.

Why another vantage point matters

A network failure is always observed from somewhere.

Suppose github.com is unreachable from my workstation.

I can test DNS:

dig github.com

Then TCP:

nc -vz github.com 443

Then TLS:

openssl s_client -connect github.com:443

Maybe I inspect my routes, VPN, proxy settings, or firewall.

Those tests are useful, but they all share one property: they are observing the network from the same machine.

Trying the same destination from another machine gives me a new piece of evidence.

Imagine this:

Thelio:
DNS       PASS
TCP 443   FAIL

Ideapad:
DNS       PASS
TCP 443   PASS
TLS       PASS
HTTPS     PASS

That difference is interesting.

GitHub clearly is not universally unreachable. The second machine just reached it.

Now I have a much smaller problem to investigate: what is different about the path from Thelio?

That is often more useful than running another five commands on Thelio.

Turning that into a command

Network Doctor already runs network checks as a dependency graph.

For an HTTPS target, for example, it can test things such as the local interface, DNS resolution, TCP connectivity, TLS, HTTP, routing, and path MTU.

Normally:

netdoc github.com

means:

Diagnose github.com from this machine.

With --via:

netdoc --via ideapad github.com

it becomes:

Diagnose github.com from ideapad.

The SSH machine is the vantage point. My local machine is just controlling the run and displaying the result.

That distinction becomes especially useful with service profiles.

For example:

netdoc --via ideapad --profile github

The GitHub profile independently checks GitHub's website, API, normal SSH endpoint, and alternate SSH endpoint.

So I can ask a more useful question than simply "can the other computer ping GitHub?"

I can ask whether the actual service paths I care about work from there.

It also works across operating systems

One of my tests involved a Linux workstation controlling a Windows machine over SSH.

The command was still just:

netdoc --via ideapad --profile github

The remote worker ran on Windows, while I launched and viewed the diagnosis from Linux.

I like this because the two machines do not need to be identical.

In fact, sometimes it is more interesting when they are not.

A Windows laptop and a Linux workstation might have different DNS configuration, routes, VPN software, firewall rules, interfaces, or network locations.

Those differences are exactly what can make a second vantage point useful.

This is not just "run the command over SSH"

I could obviously do this:

ssh ideapad netdoc github.com

And sometimes that is perfectly sufficient.

The reason I wanted remote execution inside Network Doctor is that the location of the probe becomes part of the diagnostic model.

That means the same mechanism can be used with profiles and structured output instead of treating the remote command as an unrelated terminal session.

For example:

netdoc --via ideapad --profile github

still means "run the GitHub diagnostic profile," while ideapad answers the separate question of where those probes should originate.

I think that separation is useful:

What should I test?     --profile github
Where should I test it? --via ideapad

What this can tell you

A second vantage point does not magically identify every network problem.

But it can eliminate a lot of possibilities quickly.

If the same destination fails from both machines in the same way, that is evidence that the issue may not be specific to one host.

If it fails from one machine but works from another, host-specific or path-specific explanations become much more interesting.

If DNS answers differ, investigate DNS.

If DNS agrees but TCP connectivity differs, look farther down the path.

If TCP succeeds from both but TLS fails from only one, that is another useful distinction.

The important part is not simply having more probes.

It is having different observations that can disagree.

Disagreement is often where the useful information is.

The larger idea

Network troubleshooting tools usually become collections of tests:

ping something.

Resolve something.

Open a socket.

Inspect a route.

Check a certificate.

Those are necessary, but I am increasingly interested in the reasoning that connects the observations.

A diagnostic tool should help answer:

What does this result rule out?

Remote diagnosis adds another way to obtain that evidence.

Instead of endlessly probing the same broken machine, sometimes the best next probe is the same test from somewhere else.

That is now one command in Network Doctor:

netdoc --via another-machine target

Network Doctor is open source, and I would especially like to hear about cases where comparing two machines gives a misleading result or where the remote diagnosis reaches the wrong conclusion.

Those are the interesting bugs.

https://github.com/heymaikol/network-doctor

DEV Community: Michael Placzek

I Stopped Trying to Prove My Code Works. I Started Trying to Prove It Wrong.

The happy path is the easy part

IPv6 has been particularly good at humbling me

Then I started attacking the simulator

My new rule: prove the bug before fixing the bug

A green checkmark does not mean "correct"

Strangely, this has made AI more useful

This feels slower

I don't want tests that agree with me

Combating AI Slop in Network Doctor

Rule 1: prove the bug exists

Rule 2: AI does not get to declare itself correct

Rule 3: turn important assumptions into executable rules

Rule 4: protect the boring contracts

Rule 5: fuzz the places where cleverness gets dangerous

Rule 6: replay reality

Rule 7: use AI against AI

Rule 8: test the actual platforms

Rule 9: keep changes small enough to understand

The goal is not "AI-free" code

I spent months building an open-source network diagnostic tool. Now I’m trying to make my first dollar.

The project has made $0

Paid help, not a paid binary

Looking for Contributors: Good First Issues in Network Doctor

Good first issues

#110 - Make the causal-evidence golden mutation test non-vacuous

#111 - Add hermetic tests for macOS and Windows SSID command wrappers

Looking for something more involved?

#97 - Bound hunt shard inputs before netdoc-sim merge decodes them

Ping Works, but HTTPS Doesn't: How to Find What Actually Broke

What ping actually proves

DNS can still be the problem

TCP can fail even when ping succeeds

TCP working still doesn't prove HTTPS works

And TLS working doesn't prove HTTP works

Don't forget proxies

Path MTU problems are another nasty case

The useful question isn't "does the network work?"

Doing this manually

The reverse is also true: ping can fail while everything works

A better troubleshooting habit

Debugging a Network Problem From Another Machine

Why another vantage point matters

Turning that into a command

It also works across operating systems

This is not just "run the command over SSH"

What this can tell you

The larger idea

#97 - Bound hunt shard inputs before `netdoc-sim merge` decodes them