Read logs and pinpoint errors quickly

Set the level first

log-level has five settings: silent, error, warning, info and debug. For a client that just sits there, warning is the sensible resting state — output only when something is actually wrong. Switch to info temporarily when you want to see which rule each connection matched.

Keep debug for an active investigation and turn it off afterwards. It scrolls faster than anyone can read, and the practical concern is that it records every domain you touch — which most clients are also writing to a log file on disk.

What a line contains

At info the valuable lines are connection lines: timestamp, level, the target of the request (hostname or IP with port), the rule type and pattern that matched, and the exit it ended up using. With those three facts together, why did this site take the wrong route stops being a guess and becomes something you read off the screen.

The other family is the core reporting on itself: config loaded, listener started, DNS initialised, TUN interface created. Those cluster in the first few seconds after startup and rarely appear again.

Question one: which rule caught this site

1. Set log-level to info and reload the config.
2. Clear the log pane, then close your other browser tabs — background requests will otherwise bury the line you are looking for.
3. Visit only the site in question, then read the lines that appeared and find the hostname.
4. Look at the rule it matched. If that is not the rule you wrote, something earlier in the list matched first: rules are evaluated top to bottom and the first hit wins.

Question two: the client will not start

Read the first dozen lines and nothing else. A config parse failure always happens during loading, and the message usually names the offending field and sometimes the line — a proxy-groups entry pointing at a node name that does not exist, or a field given the wrong type. Find that line, fix the corresponding place in the config.

If instead the early lines say a listener could not start, the config is fine and the port is taken. The log names the port number, so either change it or hunt down whatever process is holding it.

Question three: it keeps dropping

Here you are not reading one line, you are looking for a repeating pattern. Search for timeout, EOF, connection reset, i/o timeout and similar, then answer one question: are they concentrated on a single node, or spread across all of them? On one node, switch nodes and you are done. Across all of them, the problem is more likely in your local network or DNS than anywhere along the proxy chain.