Inconsistent connectivity to SFTP server using SFTPGo

Questions / Help
, ,
1

I need to spin up a quick SFTP server, and I’m using SFTPGo. I’m having an issue where I can always access the web UI service for this server, but SFTP connections are hit or miss. Sometimes I can connect via my SFTP client; but sometimes (often) I get this type of connection failed message in my client (typically I use Cyberduck for Mac):

image
image464×186 20.4 KB

From terminal:

image
image816×112 14.8 KB

I am definitely using the right username/ports/etc. As I said, sometimes it works. 10 minutes earlier, it was fine — now it won’t connect. I can’t figure out a pattern. At the same time as I can’t connect via SFTP (on port 2222), I have no problem accessing the SFTPGo web admin UI via the browser.

I’m not sure if this is really a Fly issue or not, but I can’t find any issues in the application server configuration. The SFTP user account in question is set to unlimited concurrent session in the SFTPGo settings, and the error message/terminal behavior suggests something networking related.

Here’s the services:

image
image1392×200 21.4 KB

fly doctor marks everything as passed.

I’ve tried explicitly binding to internal address 0.0.0.0 (see below), I’ve also tried adding a paid dedicated IPv4 address:

VERSION IP                  TYPE                            REGION  CREATED AT        
v4      [redacted]          public (dedicated, $2/mo)       global  Jun 13 2025 00:18
v6      [redacted]          public (dedicated)              global  Jun 13 2025 00:19
v4      [redacted]          public (shared)                         Jan 1 0001 00:00

Nothing seems to have made any difference. I would appreciate some direction/guidance on how to troubleshoot this further.

The fly.toml in case that’s helpful:

app = 'myappname-sftpgo'
primary_region = 'atl'

[experimental]
  cmd = ['sftpgo', 'serve']

[build]
  image = 'drakkan/sftpgo:latest'

[env]
  SFTPGO_SFTPD__BINDINGS__0__PORT = '2222'
  SFTPGO_SFTPD__BINDINGS__0__ADDRESS = '0.0.0.0'
  SFTPGO_TELEMETRY__BIND_ADDRESS = '0.0.0.0'
  SFTPGO_TELEMETRY__BIND_PORT = '9000'

[[mounts]]
  source = 'sftpgo'
  destination = '/srv/sftpgo'

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0

  [http_service.concurrency]
    type = 'requests'
    hard_limit = 250
    soft_limit = 200

[[services]]
  protocol = 'tcp'
  internal_port = 2222

  [[services.ports]]
    port = 2222

[checks]
  [checks.healthz]
    port = 9000
    type = 'http'
    interval = '5s'
    timeout = '10s'
    grace_period = '30s'
    method = 'get'
    path = '/healthz'

[[vm]]
  memory = '512mb'
  cpu_kind = 'shared'
  cpus = 1

[[metrics]]
  port = 9000
  path = '/metrics'
2

Hi… The “server may be down” tip in the error message is probably the next thing to investigate, :thought_balloon:.

Do a fly m list the next time you have trouble with port 2222—but before you try contacting any of the other ports…

(Also, start fly logs in a separate terminal and leave it running during experiments; it doesn’t always retrieve old log entries, like it’s supposed to.)

4

Incidentally, I’d also release the shared IPv4 address, since that’s probably complicating things.

(You do need dedicated addresses for port 2222.)

6

fly m list shows that the machine is running. SFTP connection fails, but web (port 80) works.

fly logs doesn’t show any indication that my SFTP connection attempt is happening. After a restart, the last log entry is:

2025-06-16T21:37:53Z app[e82dd71ae0d748] atl [info]{"level":"info","time":"2025-06-16T21:37:53.611","sender":"sftpd","message":"server listener registered, address: [::]:2222"}

And then there’s nothing logged from SFTP connection attempts. I just instantly get this in my terminal:

image
image816×112 14.8 KB

Activity in the browser via the admin panel — like as I navigate through the pages — shows in the log instantly.

7

Does the IPv4 address in sftp’s error message match the one listed for dedicated, $2/mo?

8

No, the connection rejection message was the shared IP address.

Then as suggested above, I released the dedicated address, so I only had the shared IPv4 (and the IPv6). The behavior didn’t change — connection refused.

So, I released the shared IP address, and added a dedicated IPv4 address. After waiting 10-15 minutes for DNS to update…it works. Reliably.

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.