DEV Community: Michael Placzek

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 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