I’m guessing the sshfs proxy stuff works on a different codepath to the regular https API calls, but when I try and use incus storage file edit local alloy-cfg/file.alloy I get the following output from the incus cli:
WARNING[2026-07-10T13:36:58-04:00] Failed to remove temporary file err=“remove /tmp/incus_file_edit_1760606902.alloy: no such file or directory”
Error: Failed connecting to instance SFTP: Failed to fetch https://<redacted-host>:443/1.0/storage-pools/local/volumes/custom/alloy-cfg/sftp?project=metrics: 502 Bad Gateway
Latest IncusOS, incus 7.2 yes, it’s accessing it via the tailscale services stuff I made a PR for awhile ago, so I’m not sure if it’s some kind of proxy-based blocking?
That endpoint goes through a protocol upgrade to SFTP upon connection but it’s still all encapsulated within HTTPS so while that’d likely be confusing to a terminating reverse proxy, so long as the you’re getting a TCP connection all the way into Incus, that should be fine.
Hrm. Some quick searching of the tailscale docs seems to imply it might need some changes to the tailscale service, because the https termination it uses doesn’t seem to support protocol upgrades. Only problem with that would be it’d not be https anymore… If I access the service directly using the tailscale host with :8443 it works, just not via the tailscale services proxy
Does incus use a similar protocol upgrade to websockets, or does it use ALPN, because that’s specifically what’s mentioned as unsupported by tailscale’s https termination
Hrm, maybe incusos should be using --tcp instead of --https for the tailscale serve command it runs? Where would anything be logged from the incus side for the upgrade failing? I’m not seeing anything in my syslog or incus loki logs.
Try running incus monitor --pretty that would show you any log message coming out of Incus.
Though we tend to be purposefully light on debugging that early on in connections so we can’t have users DoS the system just through port scanning and other partial connections.