Tokyo Connection Notes

Note 04 · Boundaries

Read a failure one layer at a time

A connection can fail before a name is resolved, during a secure handshake or after a request arrives. Naming the layer narrows the next check.

Ask how far the request travelled

A lookup error occurs before the client has a usable address. A connection timeout is a different observation. A certificate warning indicates that the request reached a secure endpoint but did not satisfy an identity check. An application error comes later still.

These labels do not reveal every cause. They do identify a useful boundary, which is enough to avoid changing several unrelated settings at once.

Change one condition

Choose a small request whose expected result is clear. Repeat it after changing one relevant condition, and keep the other conditions stable. If both the destination and the network change, a different result is harder to interpret.

A separate working request can be a control, provided it answers the same narrow question. A working text page does not establish that a different account operation or large download will work.

Preserve the original symptom

Write down the error category before trying a repair. A later successful refresh is useful evidence, but it does not explain the earlier failure on its own. Record what changed and whether the result repeated. That leaves a clear place to resume if the symptom returns.