Saltar al contenido

Esta página aún no está en su idioma. Está leyendo el texto en inglés.

Knowledge base

The server refused the connection: check the SSH address and port. The profile was not launched

Two halves matter here. The first says what happened at your server, and the second says the profile was not launched, which is the whole point: without the tunnel the browser would reach the site as this computer.

The profile stayed closed

Refused means nothing opened. A window brought up without the tunnel would hand the site your real address while the profile claimed an exit somewhere else.

Every road into a launch behaves the same way here, including a schedule and a flow run.

A refusal here is cheaper than a leak

Nothing about the profile changes and nothing is sent. You get the window back with a reason instead of a session opened from the wrong address.

The port is the usual cause

Refused is what a machine says when it was reached and nothing was listening on that port. SSH sits on port twenty two by default and hosting providers move it often.

Compare the port in the proxy entry with the one the server actually uses.

The address points elsewhere

A name that still resolves to a machine you no longer rent answers exactly like a closed port. The entry in the library keeps pointing at the old one until you change it.

A firewall sits in between

A provider firewall, a cloud security group or rules on the server itself can turn away connections from your address. From this side that is indistinguishable from nothing listening.

Try the same address and port from another network before you change anything on the server.

Check it before you launch

The check button on the proxy entry raises a real tunnel and takes it down again, so it fails for the same reason a launch would.

It gives the tunnel twenty seconds to come up before it calls the attempt over.

Collecting the evidence

Press Check on the entry so the refusal is fresh, and write down the exact time and the profile name.

Write from the Support screen. The report that travels with the message never carries your server password or key file: those are cut out before it leaves this computer.

What this article does not cover

  • A login the server turned down. That line names the user name key or password instead.
  • A server key that changed. That line offers to forget the old key and try again.
  • Setting up an SSH server. This article is about reaching one that already runs.

Where this is decided

Each claim above is one place in the code and one stand.

A real tunnel is raised against a real server and a profile without one does not open
apps/desktop/test/выход-по-ssh.js
A profile whose exit cannot be used is never opened directly
apps/desktop/test/прокси-с-паролем-живьём.js
The check button travels the same road a launch travels
apps/desktop/test/proxy-check-uses-bridge.js
A refusal carries its reason rather than dropping quietly
apps/web/test/отказ-не-молчит.js

Questions

Is my password visible to other programs?
No. It is handed over through a private channel on this computer, and on Windows a key file is required because a password could not be passed safely there.
Could the profile go online directly instead?
Never. A tunnel that is not up means the profile does not open, and that rule has no exception.
Which port does the browser use?
A local port on this computer that the tunnel holds. The browser talks to that port and knows nothing about SSH.

Still stuck

Support reads the report that travels with your message and answers with the cause, not with a checklist.