Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
Definition of done
The cause is found and stated in one plain sentence here: why netwatch shows these hosts as "timeout" or "unreachable" while curl reaches them from the same machine.
Every host in your list that curl reaches from netwatch's machine shows as reachable in netwatch, with a figure.
"timeout" and "unreachable" are shown only when the host really fails to answer within the stated limit.
A test covers the case that failed.
Model: opus-5-5
Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
## Definition of done
- [ ] The cause is found and stated in one plain sentence here: why netwatch shows these hosts as "timeout" or "unreachable" while `curl` reaches them from the same machine.
- [ ] Every host in your list that `curl` reaches from netwatch's machine shows as reachable in netwatch, with a figure.
- [ ] "timeout" and "unreachable" are shown only when the host really fails to answer within the stated limit.
- [ ] A test covers the case that failed.
Model: opus-5-5
clawbot
self-assigned this 2026-10-25 02:51:27 +01:00
Plan. The checks run in the browser, not on the server: measureLatency in web/src/main.js sends a no-cors GET to each URL and times it. From this host, curl reaches every Hetzner host on the list, but the Hetzner servers close the connection without an answer to a HEAD request or to a URL with a query string, so they refuse some kinds of request. s3.me-south-1.amazonaws.com does not answer curl from this host at all.
One worker, one PR into next:
Reproduce the failure in the containerised headless Chrome that script/frontend-viewport-test uses, on a network with internet access, with the built page. Read the reason each failed check writes to the debug log, and compare with curl from the same network.
Fix the cause in web/src/main.js, add a test for the case that failed to test/unit/main.test.js, and keep the Latency measurement section of README.md true.
State the cause here in one plain sentence.
A host that curl cannot reach from the same machine either is not shown as reachable; the PR body says which.
Model: opus-5-5
Plan. The checks run in the browser, not on the server: `measureLatency` in `web/src/main.js` sends a `no-cors` GET to each URL and times it. From this host, `curl` reaches every Hetzner host on the list, but the Hetzner servers close the connection without an answer to a HEAD request or to a URL with a query string, so they refuse some kinds of request. `s3.me-south-1.amazonaws.com` does not answer `curl` from this host at all.
One worker, one PR into `next`:
1. Reproduce the failure in the containerised headless Chrome that `script/frontend-viewport-test` uses, on a network with internet access, with the built page. Read the reason each failed check writes to the debug log, and compare with `curl` from the same network.
2. Fix the cause in `web/src/main.js`, add a test for the case that failed to `test/unit/main.test.js`, and keep the Latency measurement section of `README.md` true.
3. State the cause here in one plain sentence.
A host that `curl` cannot reach from the same machine either is not shown as reachable; the PR body says which.
Model: opus-5-5
Cause: the Hetzner speed-test servers drop any request that carries a Referer header, and the browser added one to every check unless the page was served with the Docker image's Referrer-Policy: no-referrer header.
Fix: #192. s3.me-south-1.amazonaws.com stays a timeout: curl from the same machine gets no answer from it either.
Model: opus-5-5
Cause: the Hetzner speed-test servers drop any request that carries a `Referer` header, and the browser added one to every check unless the page was served with the Docker image's `Referrer-Policy: no-referrer` header.
Fix: https://git.eeqj.de/sneak/netwatch/pulls/192. `s3.me-south-1.amazonaws.com` stays a timeout: `curl` from the same machine gets no answer from it either.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
Definition of done
curlreaches them from the same machine.curlreaches from netwatch's machine shows as reachable in netwatch, with a figure.Model: opus-5-5
Plan. The checks run in the browser, not on the server:
measureLatencyinweb/src/main.jssends ano-corsGET to each URL and times it. From this host,curlreaches every Hetzner host on the list, but the Hetzner servers close the connection without an answer to a HEAD request or to a URL with a query string, so they refuse some kinds of request.s3.me-south-1.amazonaws.comdoes not answercurlfrom this host at all.One worker, one PR into
next:script/frontend-viewport-testuses, on a network with internet access, with the built page. Read the reason each failed check writes to the debug log, and compare withcurlfrom the same network.web/src/main.js, add a test for the case that failed totest/unit/main.test.js, and keep the Latency measurement section ofREADME.mdtrue.A host that
curlcannot reach from the same machine either is not shown as reachable; the PR body says which.Model: opus-5-5
Cause: the Hetzner speed-test servers drop any request that carries a
Refererheader, and the browser added one to every check unless the page was served with the Docker image'sReferrer-Policy: no-referrerheader.Fix: #192.
s3.me-south-1.amazonaws.comstays a timeout:curlfrom the same machine gets no answer from it either.Model: opus-5-5