Which Protocols Does This Public VPN Node Really Offer?

The software supports it, therefore the node offers it. That inference is wrong often enough to be a rule: a SoftEther deployment can enable any subset of its compatible connection methods, and a public node is a deployment with an owner and a configuration. What you can connect with depends on that node, not on the feature list of the project it runs. The gap between the two is where most "the protocol is broken" tickets actually live.

What the project list actually promises

The project's protocol functions describe what the server is capable of. A given node enables some of those listeners and not others, and the operator can change that set without touching the software version. Two nodes on the same build therefore behave differently, and a profile that works against one proves nothing about the next target. The node's own listing outranks the project page when you are choosing where to connect.

Read the listing as five fields, not as a menu: endpoint, port, transport, protocol family and authentication method. A public node that advertises SSTP has told you about a listener on a port; it has not told you which certificate it presents or whether your account works there. Comparing those five fields against your profile is faster than any amount of client reinstallation, and it produces a written expectation you can test against later.

Match the profile to the endpoint it names

A native SoftEther entry is not automatically an OpenVPN configuration, even when both appear on one provider page under one heading. When a node publishes both a TCP and a UDP listener for OpenVPN, treat them as two endpoints: a profile edited from one to the other points at a listener nobody enabled. The transport label in the file is part of the address, not a cosmetic setting.

An imported file being accepted by the client establishes that the file parses. It says nothing about whether a remote listener waits at the other end, which is why the first connection attempt is the real test. Compare the profile's remote line with the node's advertised host and port before blaming the protocol.

Probe the stage that fails

A host that answers web traffic can still lack the intended VPN service, and a host that refuses one protocol is not necessarily down for all of them. Those two mistakes send people in opposite directions on the same afternoon. One chases a firewall that is fine; the other reinstalls a client that was never the problem. Probe each path separately so the answer describes one listener rather than the whole host.

These five checks cover the common public-node methods. Run them from the same network the client uses, because a filtered port looks identical to a missing listener from further away.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

Attach each observed error to its row before changing anything. A TLS identity failure proves the listener exists, so rewriting the profile to another protocol would discard working evidence. A refused connection proves only that this port did not answer, which is a much narrower statement than "the node does not support OpenVPN".

Preserve the error before changing anything

Write down the exact result: a timeout, a certificate identity failure, an account rejection and an application-level denial are four different outcomes. Only the first one is about a protocol being unavailable, and only the last one is about permission after a successful connection. Resetting the client or swapping protocols destroys that distinction, because the next failure arrives with a different history and no baseline to compare against.

Do not weaken verification to make an incompatible profile appear to work. A disabled certificate check turns a clear identity failure into a connection to something you did not intend to reach, and the resulting success is worse than the original error because it hides which stage was wrong.

Re-check per node, every time

The native SSL, OpenVPN, L2TP/IPsec and SSTP choices on a public node listing describe that node's configuration at that moment. The same software elsewhere can present a different set, and a provider can retire a listener between your bookmark and your next attempt. Old notes describe old deployments.

Record the verified profile with its endpoint and method, then repeat the probe when the node changes or the connection starts failing. The SoftEther protocol specification is the reference for what the software can do; the node's own listing is the reference for what it does. Keep the two documents apart and the diagnosis gets shorter.