SSTP is PPP over HTTPS, not a web page on port 443

SSTP carries PPP inside an HTTPS connection, which is why it looks like web traffic to anything in the middle. TLS and HTTP establish the outer channel, then SSTP control messages prepare the tunnel, and PPP supplies the session behaviour. A browser that loads a page at the same address has completed only part of the first stage. Treating that as a VPN test is how a working proxy gets blamed for a protocol mismatch.

Walk the four stages in order, and the failure you are seeing lands in one of them.

Stage 1: TCP and TLS

The client opens a TCP connection to port 443 and performs a TLS handshake. The certificate chain has to match the hostname the client was configured with. A name mismatch here produces a failure before any SSTP message is exchanged, and the SSTP specification assumes this outer HTTPS channel already exists. Nothing in the later stages can compensate for a trust failure here.

A generic web server can complete this stage perfectly and still fail the next one. TLS success is evidence about the certificate, not about the protocol behind it.

Stage 2: the HTTPS request

SSTP makes its request with a specific method, SSTP_DUPLEX_POST, and keeps the exchange open instead of returning a document. A server or proxy configured for ordinary page requests may accept the connection and then reject the method. That rejection is the compatibility problem people usually describe as port 443 being blocked.

Read the response code and the method in the server log. A rejection at this stage is a different problem from a TCP timeout, and the two lead to different fixes.

Stage 3: control messages

Once the request is accepted, SSTP exchanges control messages that negotiate and prepare the tunnel. These are protocol messages inside the HTTPS body rather than HTTP requests, so a proxy that inspects and rewrites bodies can break them while leaving page requests untouched.

This is where a deep-inspection middlebox earns its reputation. If pages load and the VPN fails, check whether the body is being modified rather than whether the port is open.

Stage 4: PPP takes over

PPP then provides its session behaviour: link negotiation, authentication, and the network-layer configuration that follows. PPP authentication is separate from the TLS check the client already passed. A server certificate the client accepts says nothing about whether the user's credentials are valid or the account is authorized.

An accepted certificate and a rejected login are not contradictory. They are consecutive stages with independent outcomes.

Authentication has several roles

The client validates the TLS server identity against its trust store and the configured name. PPP then authenticates the user or the machine, depending on the deployment. The server may add its own policy about who may connect and what they may reach. Keep the hostname consistent with the certificate identity, because substituting a raw address turns a working setup into a name-check failure.

Write down which stage reported the failure. Certificate, method, control message, PPP authentication, then routes: five places, five repairs.

What a browser test can and cannot show

Loading a page at the address proves DNS resolution, TCP reachability, and something listening that speaks HTTP. It does not prove the method is accepted, the control exchange survives, or PPP authentication is configured. Use a client that implements SSTP rather than converting another profile by changing the port.

Once the session is up, routes, DNS and server-side forwarding still decide what the user can reach. The tunnel is a path, not an authorization.