SSH WebSocket profiles are easier to troubleshoot when you separate account credentials from transport settings. The username and password identify the SSH account, while the host, port, path, payload, and TLS options describe how the client should reach the server. Mixing values from different pages is one of the most common reasons a valid account fails to connect.
Check the server page first
Before opening HTTP Injector or HTTP Custom, confirm that the host supports WebSocket and that the server is online. Read the country, hostname, port, WebSocket path, and any TLS or payload notes as one complete profile. If the page lists a different SSH method, do not force it into a WebSocket template.
Enter the account and transport separately
Use the generated username and password only in the SSH account fields. Enter the hostname and port in the connection section, then add the WebSocket path or payload exactly as published. A typo in a slash, port, or host can create the same error as an invalid password, so change one value at a time while testing.
Keep TLS optional until it is required
TLS is not automatically needed for every WebSocket host. Enable it only when the service page and client instructions provide the required domain or SNI value. If the server uses plain WebSocket, adding an unrelated TLS setting can prevent the handshake from completing.
Test and protect the profile
Save a private copy of the working profile and remove credentials before sharing screenshots. If the account expires, create a new account and recheck the server details instead of reusing an old profile with a new host.
