self hosting, no route to host

[xxdesmus]

I am self hosting the hishtory server via Docker. Using this container: https://docs.linuxserver.io/images/docker-hishtory-server/ and postgres.

When I try to connect a MacOS laptop to the new server I get the following error:

hishtory init
Your current hishtory profile has saved history entries, are you sure you want to run `init` and reset?
Note: This won't clear any imported history entries from your existing shell
[y/N]y
Setting secret hishtory key to XXXXXXXXX
2025/01/03 21:25:54 hishtory v0.313 fatal error at github.com/ddworken/hishtory/client/cmd/install.go:89: failed to register device with backend: failed to GET http://192.168.7.134/api/v1/register?user_id=XXXXXXXX=&device_id=YYYYYYY: Get "http://192.168.7.134/api/v1/register?user_id=XXXXXXXX=&device_id=YYYYYYY": dial tcp 192.168.7.134:80: connect: no route to host

even though I am can reach the IP without issue otherwise:

sudo mtr -r 192.168.7.134
Start: 2025-01-03T21:25:59-0800
HOST: XXXXXX                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.7.134              0.0%    10   10.6  10.8   8.3  15.9   2.3

The server is set as follows:

export HISHTORY_SERVER=http://192.168.7.134

echo $HISHTORY_SERVER
http://192.168.7.134

I tried creating an internal DNS hostname as well (using Adblock Home) and it also fails.

export HISHTORY_SERVER=http://hishtory.local

hishtory init
Your current hishtory profile has saved history entries, are you sure you want to run `init` and reset?
Note: This won't clear any imported history entries from your existing shell
[y/N]y
Setting secret hishtory key to XXXXXXXXX
2025/01/03 21:30:49 hishtory v0.313 fatal error at github.com/ddworken/hishtory/client/cmd/install.go:89: failed to register device with backend: failed to GET http://hishtory.local/api/v1/register?user_id=XXXXXXXX=&device_id=YYYYYYY: Get "http://hishtory.local/api/v1/register?user_id=XXXXXXXX&device_id=YYYYYYY": dial tcp: lookup hishtory.local: no such host

even though the hishtory.local value can be correctly resolved via the DNS resovler.

dig hishtory.local

; <<>> DiG 9.10.6 <<>> hishtory.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hishtory.local.			IN	A

;; ANSWER SECTION:
hishtory.local.		10	IN	A	192.168.7.134

;; Query time: 42 msec
;; SERVER: 192.168.7.240#53(192.168.7.240)
;; WHEN: Fri Jan 03 21:31:19 PST 2025
;; MSG SIZE  rcvd: 48

Any ideas?

[ddworken]

Huh, that is interesting--I'm not really sure why the hishtory binary would be having trouble connecting if the connection is otherwise working. I'm wondering: Does http://192.168.7.134/healthcheck return OK? That would confirm that the network connection is fully working and that the server is working properly.

[xxdesmus]

The health check returns "OK" to make things even stranger. 😂

[ddworken]

Interesting... Ok, next step--can you download this gist and then run it (e.g. save it as nettest.go and then go run nettest.go) and let me know what it outputs?

[xxdesmus]

Here's the output:

go run nettest.go
http.Get Response: (*http.Response)(nil)
http.Get Error: &url.Error{Op:"Get", URL:"http://192.168.7.134/healthcheck", Err:(*net.OpError)(0x140000e80f0)} -- Get "http://192.168.7.134/healthcheck": dial tcp 192.168.7.134:80: connect: no route to host
http.Get Response: (*http.Response)(nil)
http.Get Error: &url.Error{Op:"Get", URL:"http://192.168.7.134/healthcheck", Err:(*net.OpError)(0x140000e8230)} -- Get "http://192.168.7.134/healthcheck": dial tcp 192.168.7.134:80: connect: no route to host

I created a copy of the file and tried the same test but requesting https://api.hishtory.dev/healthcheck and I get the following:

go run nettest-publicURL.go
http.Get Response: &http.Response{Status:"200 OK", StatusCode:200, Proto:"HTTP/2.0", ProtoMajor:2, ProtoMinor:0, Header:http.Header{"Alt-Svc":[]string{"h3=\":443\"; ma=2592000"}, "Content-Length":[]string{"2"}, "Content-Type":[]string{"text/plain; charset=utf-8"}, "Date":[]string{"Sun, 05 Jan 2025 21:24:52 GMT"}, "Server":[]string{"Caddy"}}, Body:http.http2transportResponseBody{cs:(*http.http2clientStream)(0x140000f0180)}, ContentLength:2, TransferEncoding:[]string(nil), Close:false, Uncompressed:false, Trailer:http.Header(nil), Request:(*http.Request)(0x14000130140), TLS:(*tls.ConnectionState)(0x140000ee0c0)}
http.Get Error: <nil> -- %!s(<nil>)
http.Get Response: &http.Response{Status:"200 OK", StatusCode:200, Proto:"HTTP/2.0", ProtoMajor:2, ProtoMinor:0, Header:http.Header{"Alt-Svc":[]string{"h3=\":443\"; ma=2592000"}, "Content-Length":[]string{"2"}, "Content-Type":[]string{"text/plain; charset=utf-8"}, "Date":[]string{"Sun, 05 Jan 2025 21:24:52 GMT"}, "Server":[]string{"Caddy"}}, Body:http.http2transportResponseBody{cs:(*http.http2clientStream)(0x140001da000)}, ContentLength:2, TransferEncoding:[]string(nil), Close:false, Uncompressed:false, Trailer:http.Header(nil), Request:(*http.Request)(0x140001c2280), TLS:(*tls.ConnectionState)(0x140000ee0c0)}
http.Get Error: <nil> -- %!s(<nil>)

[ddworken]

Huh, that is truly bizarre that curl can reach it but Go's http library can't. I spent some time poking through different corners of Go's HTTP library to see if I could come up with any theories as to what is going on here, but I'm a bit stumped. A few potential questions that might help debug this:

1. What OS is the server hosted on? Is it also macos? If so, I'm wondering if you're running into something related to this and restarting docker/clearing out networks might help?
2. Have you tried setting up hishtory on another machine talking to this server? Does that work?

[withnale]

I have seen this on numerous occasions on my machine. There are some differences with the go networking stack and the normal networking stack and it bites me quite often. It's hard for me to pin down why it occurs. In these scenarios I quite often see that curl can reach an endpoint but any golang based application (such ashey) cannot with a no route to host message.

I've read in various places that the golang network stack wires into IPV6 as well as IPV4 by default and the problem might be there. There is also some discussion that it's MacOS security related and iTerm losing the ability to bind to the Local Network, as detailed here: https://gitlab.com/gnachman/iterm2/-/issues/12106 - however for me curl always works so maybe that's not the case.