Technical Diagnosis — Daniel Taylor

The problem

A Fedora laptop using ProtonVPN could not reach a satisfactory browsing state. The failure crossed several networking layers, so there was no single obvious place to assign blame.

Possible contributors included IPv6 routing, VPN behavior, the operating system's proxy path, and Brave's DNS handling. The practical objective was not to prove a preferred theory; it was to get the connection working normally while using each test result to narrow the problem.

Fedora Linux ProtonVPN Brave Browser IPv6 proxy DNS

Diagnostic principle

A failed test is not wasted effort. If an intervention changes nothing, it eliminates or weakens one explanation. If it changes the symptom without fully solving the problem, the new behavior becomes evidence about which layer to inspect next.

Why this was a useful AI-assisted debugging problem

Multiple layers

VPN tunneling, IP routing, OS proxy settings, browser behavior, and DNS resolution can interact while presenting as one vague “internet problem.”

Incomplete observability

No single symptom identified the responsible layer. The system had to be interrogated through configuration checks and controlled changes.

Model revision

The first plausible hypothesis did not solve the issue. Progress required updating the model rather than repeating or defending the initial theory.

Diagnostic sequence

Step 01

Inspect the network state

IPv6 routing was inspected using system-level evidence rather than guessing from browser behavior alone.

ip -6 route

Result: IPv6 became a plausible test target

Step 02

Test the IPv6 hypothesis

IPv6 was disabled as a troubleshooting test.

Result: the connection problem remained

Model update: IPv6 alone was not sufficient to explain the failure. The hypothesis was weakened instead of being treated as the answer because it sounded technically plausible.

Step 03

Change the system proxy path

Turning on the computer's proxy setting changed the behavior: browsing became possible.

Result: connectivity restored, but performance became very slow

Model update: this was not a complete solution, but it was highly informative. The failure had shifted from “cannot connect normally” to “can connect through this path, but with severe latency.”

Step 04

Use the browser-specific symptom

Because the connection now worked but browsing remained abnormally slow, attention shifted from broad network availability toward Brave's own network-resolution behavior.

Result: browser DNS behavior became the next discriminating variable

Step 05

Disable Brave Secure DNS

Brave's Secure DNS setting was turned off.

Result: pages returned to normal loading speed

The practical problem was resolved. The evidence supported a configuration interaction involving browser-level Secure DNS strongly enough to stop troubleshooting, without claiming more protocol-level certainty than the tests established.

How each result changed the working model

Test	Observed result	Reasoning update
Inspect IPv6 routes	IPv6 was active and worth testing.	Generated a plausible hypothesis; did not establish causation.
Disable IPv6	Problem persisted.	Reject IPv6 as a sufficient explanation and move on.
Enable system proxy	Connection worked, but browsing slowed considerably.	Treat partial improvement as evidence about the network path, not as “fixed.”
Disable Brave Secure DNS	Normal page-loading speed returned.	Stop at the simplest explanation consistent with the observed configuration changes.

The transferable reasoning pattern

Observe→ Generate hypothesis→ Change one variable→ Measure result→ Update model→ Choose next discriminating test

What did not happen

the first plausible explanation was not promoted to certainty
a failed intervention was not repeated without new evidence
partial success was not confused with full resolution
the troubleshooting did not expand indefinitely after normal behavior returned

What did happen

system evidence was collected
hypotheses were tested sequentially
negative results reduced the search space
new symptoms redirected attention to a different layer
the final claim was kept narrower than the available evidence

Human–AI division of labor

Human responsibility

observe the actual machine and report what changed
run commands and configuration tests
distinguish “still broken,” “different,” and “resolved”
reject suggestions that do not match the evidence
decide when the practical problem is solved

AI contribution

generate plausible causes across several system layers
interpret command output and reported symptoms
propose discriminating next tests
revise hypotheses when interventions fail
help maintain continuity across the troubleshooting sequence

What this case demonstrates professionally

The value of this case is not specialized expertise in one VPN product. It demonstrates a general method for working with AI on real systems where the model cannot directly observe the environment: the human supplies ground truth, the AI supplies analytical breadth, and both sides iterate against evidence.

technical QA root-cause investigation hypothesis testing Linux troubleshooting AI-assisted debugging evidence-based iteration uncertainty calibration

Result

Resolved state:

The connection became usable after enabling the system proxy, and normal browsing performance returned after Brave Secure DNS was disabled. The failed IPv6 intervention and the proxy's partial improvement were retained as evidence in the reasoning chain rather than discarded as irrelevant detours.