VPN Gate and Your Own SoftEther Server Are Not the Same Thing
Same protocol, same client, different operator. See who publishes the endpoint, whose logging policy applies, and why a public node is not private access.
A team installs a SoftEther server, exports a connection setting, and someone later finds the same protocol in a public VPN Gate directory and asks whether the company now runs a public relay. The confusion is understandable: the client looks identical, the protocol is identical, and both appear in the same kind of connection list. The distinction is not technical, it is operational. A server you deploy belongs to whoever deployed it, and VPN Gate is a separate volunteer project that publishes endpoints of its own.
Same client, two different operators
Three questions separate the two deployments, and none of them is answered by the software. They are worth writing down before anyone compares clients.
| Question | Your SoftEther server | A VPN Gate volunteer node |
|---|---|---|
| Who runs it | you, or your hosting provider on your behalf | an anonymous volunteer |
| Who may connect | accounts you create | anyone using the public directory |
| Who writes the logging policy | you | the volunteer, within the project's published rules |
The middle row settles most arguments. On your own server the account list is something you control, so membership means something; on a volunteer node every directory user is a potential peer on the same endpoint. That row also cannot be inferred from the client, which is why two people with identical software can be describing completely different networks.
Read who published the endpoint
Start with the source of the connection setting. A directory entry with a volunteer host name, a rotating address and a public listing is a different object from a configuration your administrator exported with your own host name and certificate. If the endpoint appears in a public list, treat it as public, because that is exactly what the listing means. Nothing about the protocol changes the answer.
A directory entry is also not administrative access. Being able to connect to a node says nothing about its management interface, and trying management credentials on a volunteer host is both ineffective and inappropriate. Use the connection method the listing offers and nothing beyond it.
Logging follows the operator, not the protocol
SoftEther as software can log connections, and the administrator of a server decides what is kept and for how long. VPN Gate publishes its own pages about the volunteer model and about anti-abuse logging, and those pages are the only accurate statement about that project. Reading them is a different act from assuming that any SoftEther-based service keeps nothing, which is a claim the software cannot support.
For your own server, the equivalent statement comes from your configuration and your retention policy. That may be more logging than a public node keeps, or less, and it is your responsibility either way. Anyone who says the protocol guarantees anonymity is describing a hope rather than a design.
A public exit is not membership in a private network
The practical failure arrives when someone needs an internal service and reaches for a free public exit instead of the company gateway. A public node can change the address your traffic appears to come from. It cannot make you a member of a network you were never granted access to, and no client setting changes that. The reachable set is defined at the far side, by whoever runs the gateway.
This is also where security policy belongs. Traffic through an unknown volunteer host is subject to that host's practices, and the trust decision is categorically different from traffic through a gateway your organization operates and audits. Choosing the free exit moves the trust, it does not remove it.
Decide what you are actually deploying
Three questions settle it. Who will operate the endpoint? Who is allowed to connect to it? Whose logging and retention policy applies to the traffic? If the answer to any of them is "whoever finds it", the deployment is public no matter what the protocol file says.
Write the answers next to the deployment, including the operator, the permitted users and the retention policy. When the next person finds the same protocol in a public directory, that note is the whole explanation, and it saves the argument about whether the company is running a relay.