Custom connector's "Couldn't connect to the server" error hides the real cause when the server is on a non-standard port

### What happened?

Custom remote MCP connectors fail with a generic "Nothing answered at this URL. Check it for typos before continuing." when the server is hosted on a non-standard HTTPS port (in my case, 8443). This isn't a report that the connector doesn't work on non-standard ports - that's already been established behavior in this tracker (#85, #373) and may well be an intentional constraint. This is a report that the error message actively misleads the person debugging it, sending them down the wrong path entirely.

The actual fix: front the same backend on port 443 (via a reverse-proxy hostname rule) with everything else unchanged. It worked immediately, as in the other prior reports.

The error message gives no indication that the failure is port-related, even though (per #85, #373, and third-party writeups) this is apparently deterministic and already known internally. Two possible fixes, either would help:

When the connector backend can determine the target port isn't 443, surface a specific error (e.g. "Custom connectors must be served on port 443") instead of the generic unreachable message.
At minimum, document the port-443 requirement in the custom-connector setup UI and docs, so this doesn't require firewall-log-level forensics to discover.

Prior art: #85, [#227](https://github.com/anthropics/claude-ai-mcp/issues/227), #373 all show the same "zero inbound traffic despite a working server" symptom on non-standard ports, each closed without a documented explanation reaching the reporter.

### What did you expect to happen?

I run a small self-hosted MCP bridge (CalDAV) behind an nginx TLS terminator, originally exposed on port 8443. DNS, TLS cert (valid wildcard, correct SAN, correct chain order), and nginx auth config all verified correct.
Confirmed externally reachable on 8443 from multiple independent vantage points: a random internet vulnerability scanner, a cloud-based fetch tool, and manual browser testing... all got valid HTTP responses from the box.
The custom connector in the Claude app consistently failed with the generic "couldn't connect" error.
I watched the nginx access log and my own hardware firewall's connection logs live while retrying the "Connect" flow. Zero packets ever arrived, not even an unauthenticated probe request, despite the box being demonstrably reachable from every other tested source at the same time.
This produced a long, plausible-looking debugging trail toward the wrong causes: NAT/firewall misconfiguration, TLS chain issues, ISP-level ASN filtering, DSM auto-block, none of which were the actual problem, and none of which would show any symptom distinguishable from "the connector backend simply never dials out."

### Steps to reproduce

1. Open a server on a non-standard port on any publicly-available host (e.g. 8443)
2. Configure a custom MCP connection to the non-standard port from within the desktop app preferences
3. Note that no connection attempts are ever logged from Anthropic and that the error messages on creating and re-connecting the custom MCP are misleading (referring to a bad URL or nonresponsive host) instead of flagging that this setting will never work, because the connection won't be attempted on that port.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Custom connector on personal host

### Error messages or logs

```shell
n/a
```

### Additional context

_No response_