Tool

Connection error finder

Search a message or filter by the kind of failure. Each entry explains what the wording usually means, what commonly causes it, and what you can check without weakening the session.

This page does not see your server and cannot diagnose it. The notes are patterns, not a promised fix. Do not paste passwords, private keys, or raw logs here. If you share a log elsewhere, remove secrets first. A normal session log is enough for most questions. A higher log level exists that records the password; do not turn that on if the file might leave your machine.

Connection timed out

The PC sent a connection request and nothing completed it in time. A timeout usually means packets never reached a listening service, or the reply never came back. It is not, by itself, a wrong password.

Common possible causes

  • The hostname or IP address does not point where you think it does.
  • A firewall, on your network or the server, drops the port instead of refusing it.
  • The server is offline, or the service is not running.
  • The port number does not match the protocol you selected.
  • A VPN is required and is not connected, or a VPN is changing the route.

Safe diagnostic steps

  1. Compare the hostname and port with the values the administrator wrote down, character by character.
  2. Confirm you are on the network that is allowed to reach that host. A guest Wi-Fi network often is not.
  3. Try the same protocol, host, and port in a second client only if you are allowed to. If both time out, the problem is likely outside the file client.
  4. Ask the administrator whether the service is up and whether your address must be allowed through a firewall.
  5. Do not keep changing protocols in the hope that a different default port will answer.

Relevant configuration areas

  • Login dialog: Hostname and Port number
  • File protocol, because it selects the default port
  • Any proxy or tunnel page if your site actually uses one

A timeout is not fixed by disabling host-key or certificate checks. Those checks happen after a connection exists.

Matching guides

Connection refused

A machine answered, and it actively refused the socket. Something is reachable at that address, but no service accepted the port you asked for. This is different from a timeout, where you never got an answer.

Common possible causes

  • The service listens on a different port.
  • The file service is stopped, while the computer itself is up.
  • You selected a protocol whose default port is closed on that host. Port 22 and port 21 are the common mix-up.
  • A firewall rejects the port with a reset rather than dropping it silently.

Safe diagnostic steps

  1. Check the protocol and the port as a pair. SFTP and SCP normally use 22, FTP and explicit FTPS use 21, implicit FTPS uses 990, HTTPS WebDAV and S3 use 443.
  2. Ask which port is open. Do not scan the server for open ports unless the system owner has authorized that work.
  3. If a web page on the same hostname loads, that only proves port 443 or 80. It does not prove that file transfer is enabled.
  4. If another authorized client gets the same refusal, give that fact to the administrator.

Relevant configuration areas

  • File protocol selection
  • Port number box
  • The provider’s note that names the listener, such as explicit versus implicit TLS

Matching guides

Authentication failed

The server was reached, and it rejected the proof of identity. Depending on the software, the wording may be “access denied” or “authentication failed.” The network part of the session has already succeeded.

Common possible causes

  • The username or password does not match, including a trailing space or the wrong letter case.
  • The account is locked, expired, or not allowed from your address.
  • A public key is being offered, and that key is not installed for the account.
  • The server expects keyboard-interactive or Kerberos, and a stored password is being sent instead.
  • For S3, the access key ID and secret do not match, or they have no permission to that endpoint.

Safe diagnostic steps

  1. Re-type the username. Usernames are often case-sensitive on SSH and S3.
  2. If you use a password, enter it when the application prompts. Do not paste it into a web page to “test” it.
  3. If you use a key, confirm Private key file points at the key whose public half is on the server, and that the agent is not offering a different key first.
  4. Ask the administrator to confirm the account is enabled and which method is allowed. A server log, read by the administrator, is more specific than the client message.
  5. For S3, confirm the key belongs to the same provider as the endpoint.

Relevant configuration areas

  • Username and Password boxes
  • Authentication page: Private key file, agent, keyboard-interactive, GSSAPI
  • S3: Access key ID, Secret access key, or Credentials from AWS environment

Repeated guesses can lock the account. Stop after a careful retry and ask the administrator. Never send the password or the private key to someone offering to debug it.

Matching guides

Host key verification warning

On the first SSH connection, the client has no saved host key for that server, so it shows the fingerprint and asks you to decide. On a later connection, the same style of warning means the key changed. The warning is the check working. It is not an error to click past.

Common possible causes

  • This is the first connection, and the key is simply unknown to this PC.
  • The server was rebuilt and the administrator generated a new host key.
  • You typed a hostname that reaches a different machine than last time.
  • Someone is intercepting the connection. That is the case the warning exists to catch.

Safe diagnostic steps

  1. Read the fingerprint shown in the prompt. Compare it with a fingerprint the administrator gave you by a channel you already trust, such as a ticket or a phone call they expect.
  2. Watch for characters that look alike, such as 0 and O, or 1 and l.
  3. If this is the first connection and the fingerprint matches, you can continue and the client will remember the key.
  4. If the key changed and nobody told you it would, cancel and ask why before you enter a password or use a key.
  5. After a key is trusted, you can view it later on the Server and Protocol Information dialog.

Relevant configuration areas

  • The host-key prompt on the first SSH login
  • Saved site configuration, where accepted host keys are stored
  • Scripting: the -hostkey switch, which should carry the fingerprint you already verified

Do not accept a changed key to finish a transfer. Do not use a script setting that trusts any host key. A password typed after a wrong acceptance can be captured.

Matching guides

Permission denied

The server understood the request and refused it. After a successful login, this is usually a file-permission or directory-permission problem. During login, some SSH servers use the same words for a failed authentication. The timing tells you which one you have.

Common possible causes

  • The account cannot read or write that path.
  • The remote directory is owned by another user, or a web root is not writable by the FTP account.
  • For SFTP, the operation needs a newer protocol feature or a server extension.
  • For S3, the IAM policy or bucket policy does not allow that action, even though the key is valid.
  • A parent directory does not allow traversal, so a nested path fails.

Safe diagnostic steps

  1. Note whether the message appeared before any directory listing or only after you opened a folder or started a transfer.
  2. Compare the remote path with the path in the hosting instructions.
  3. Try a directory you know the account should see, such as its home directory, before trying the web root.
  4. Ask the administrator to check ownership and mode, or the bucket policy. Do not chmod a directory you do not own in order to “test.”
  5. If the message appears at login, use the authentication entry instead of changing remote permissions.

Relevant configuration areas

  • Remote path in the file panel
  • Directories page of Advanced Site Settings, if a startup directory is saved
  • Server-side permissions or bucket policy, which the client cannot override

Making a directory world-writable to finish an upload exposes it to every account on that server. Ask the administrator for the intended permission instead.

Matching guides

Remote path not found

The session is working, and the path you asked for is not there under this account. Servers often phrase it as “no such file or directory.” A missing path is not the same as a refused connection.

Common possible causes

  • A typo, an extra slash, or a Windows-style backslash in a remote path.
  • The saved startup directory was removed on the server.
  • You are in the wrong account, so the home directory layout is different.
  • The web root moved, which is common after a hosting migration.
  • On S3, the bucket or prefix does not exist, or the key cannot list it.

Safe diagnostic steps

  1. Clear any remembered remote directory and connect to the default directory.
  2. Browse from that listing instead of pasting a long path.
  3. Check slash direction. Remote SFTP, FTP, and WebDAV paths use forward slashes.
  4. For a website, compare the path with the host’s current document root, not with an old bookmark.
  5. For S3, confirm the bucket name in the provider’s console rather than guessing a prefix.

Relevant configuration areas

  • Remote directory shown in the file panel
  • Startup directory stored with the site
  • S3 bucket and prefix

Matching guides

Transfer interrupted

The session started and the file did not finish. The client may report that the connection closed, that the copy failed, or that the transfer was aborted. What you can do next depends on the protocol.

Common possible causes

  • The network dropped, or a laptop slept.
  • A firewall idle timer cut a long transfer.
  • The disk filled up, or a quota was reached.
  • The server closed the connection because of a policy or a server-side error.
  • An SCP transfer was canceled, which ends the session in this client.

Safe diagnostic steps

  1. Check whether a partial file was left in the destination and whether its size is smaller than the source.
  2. Reconnect and retry one file before retrying a large batch.
  3. On SFTP, resume is supported when the server speaks SFTP version 2 or newer. FTP can resume. This client does not resume WebDAV or SCP transfers.
  4. If the same file fails at the same point, ask the administrator to look at the server log for a quota, a timeout, or an antivirus scanner.
  5. Avoid synchronize with delete enabled until a single-file transfer is reliable.

Relevant configuration areas

  • Transfer dialog and background-transfer option
  • Protocol selection, because resume support differs
  • Server disk quota and idle timeout, outside the client

A partial archive or database dump can be unusable and can still contain sensitive data. Delete a partial copy of a secret file rather than leaving it in a public folder.

Matching guides

Unable to establish an SFTP connection

SSH may have accepted the login, and the SFTP subsystem still failed to start. The client can report that it could not initialize SFTP and ask whether the host is running an SFTP server. Authentication and the file protocol are different steps.

Common possible causes

  • The SSH server does not have the SFTP subsystem enabled.
  • The account is limited to a shell that exits immediately, or to a subsystem path that is wrong on the server.
  • You reached a device that speaks SSH but is not a file server.
  • The server only offers FTP or FTPS, and SFTP was selected because the port happened to be open.

Safe diagnostic steps

  1. Ask the administrator whether SFTP is enabled, not only whether SSH is enabled.
  2. If they confirm SCP only, use SCP with the limitations that protocol has, or ask them to enable SFTP.
  3. If they confirm FTP or FTPS, change File protocol. Do not keep the SSH port and hope FTP will answer there.
  4. A terminal client such as PuTTY can show a banner the file client does not emphasize. Use that only on a server you are allowed to access.
  5. Check the server log if you administer the host. The subsystem line is more specific than the client dialog.

Relevant configuration areas

  • File protocol: SFTP versus SCP versus FTP
  • Server sshd configuration, which is not a client setting
  • SCP/Shell page, only if you intentionally switch to SCP

Falling back to unencrypted FTP because SFTP failed exposes the password. Ask for the correct secure service instead.

Matching guides

TLS certificate warning

FTPS or HTTPS WebDAV presented a certificate the PC does not already trust, or the name on the certificate does not match the hostname you typed. The warning is a server-identity check for TLS, similar in purpose to an SSH host key, and it uses different technology.

Common possible causes

  • The hostname in the Login dialog does not match the certificate’s name.
  • The certificate expired or was replaced.
  • The server uses a private certificate authority that is not in the Windows trust store.
  • A device on the network is substituting its own certificate.

Safe diagnostic steps

  1. Compare the hostname you typed with the name the administrator told you to use.
  2. Read the certificate dates and the subject name in the warning.
  3. If the organization uses a private authority, install or trust it only through the process your administrator documents. Do not click through a mismatch on a public network.
  4. For a script, the -certificate switch can pin the fingerprint you already verified. It should not be used to accept whatever certificate appears.
  5. Plain FTP avoids the warning by removing encryption. That is not a fix.

Relevant configuration areas

  • Hostname box
  • FTPS invocation method and port
  • WebDAV secure versus unsecured variant

Continuing past an unexpected certificate can reveal the FTP or WebDAV password. Stop and check when the certificate is new and unexplained.

Matching guides

Server closed the connection

The server, or something in front of it, ended the session after it had started. You may see a network error saying the connection was closed unexpectedly. The reason is often on the server side, which is why the client message stays general.

Common possible causes

  • Too many connections from the same account.
  • An idle timeout or a transfer-size limit.
  • The server application crashed or restarted.
  • A security rule disconnected the session after a command it did not like.
  • FTP data-channel negotiation failed and the server dropped the control connection.

Safe diagnostic steps

  1. Retry once. If it closes at the same moment, note what you had just done: login, listing, or transfer.
  2. For FTP or FTPS, treat a failure that happens when a listing should appear as a data-connection problem. Mention passive mode to the administrator.
  3. Ask the administrator to read the server log for the same timestamp. That log is the authoritative reason.
  4. Turn on a session log if you need to see the last command. Remove account names, paths you consider private, and any secret before you share the file.
  5. Do not enable a log level that records passwords if the file might be forwarded.

Relevant configuration areas

  • FTP page: listing command and passive-mode address behavior
  • Session logging, started from the application or with the /log switch
  • Server-side connection limits

The official troubleshooting notes include a higher log level that records the password. Leave that level off unless you control the file and will delete it. A normal session log is enough for most interrupted sessions.

Matching guides

For a method rather than a single message, read common connection problems.

Winsaip is an independent educational resource and is not affiliated with or endorsed by the developers of WinSCP.