"Failed to connect to remote host: <nil>" error log

[jportner]

I recently upgraded my Docker image to use the latest commit on the master branch of Smokescreen (c86310d).

Right after a connection is allowed through the proxy, I'm occasionally seeing this error log message Failed to connect to remote host: <nil> but of course <nil> doesn't contain any helpful information.

It seems like this problem might be related to the recent change in #194?
I'm not very experienced with Go but reading the code, I'm not sure how e.Error() is returning nil.

[jjiang-stripe]

Hello! Sorry for the delay on this and thanks for reporting! We actually noticed this internally too, and I dug through all the parts of the code were we pass down that error but didn't find anything suspicious :/ When we saw the issue, we were able to reproduce intermittent connection refused errors to the destination with netcat, so I think there actually was some sort of error, but we haven't been able to figure out why it's unwrapping incorrectly. I don't think #194 caused this since that error string ("Failed to connect to remote host: " is coming from the else case and we only added an extra else if in that PR.

I'll leave this open for now for us to keep digging into, but just wanted to let you know we're aware and equally confused!

[jportner]

Thank you for the update!

[alexmv]

This may be IPv6 routing related.

We got a report of a Smokescreen install with IPv6 enabled but not working (no outgoing IPv6 routes). If a destination server has both A and AAAA records, and Smokescreen chooses the ipv6 address, it logs:

{"conn_establish_time_ms":0,"id":"d5sumpb28aes1nampfh0","inbound_remote_addr":"127.0.0.1:55900","level":"error","msg":"Failed to connect to remote host: \u003cnil\u003e","project":"","proxy_type":"connect","requested_host":"redacted.example.com:443","role":"","start_time":"2026-01-28T10:56:37.411130218Z","status_code":502,"time":"2026-01-28T11:56:37+01:00","trace_id":""}

Disabling ipv6 on the host resolved the issue.

Ideally, Smokescreen would try both IPv4 and IPv6 addresses in parallel (happy-eyeballs) so that a failure of outgoing IPv6 on the server would not result in broken requests.