[BUG] WebFetch on a site that has no HTTPS fails with a bare `connect ECONNREFUSED <ip>:443`, which does not say the URL was upgraded

What's Wrong?

WebFetch upgrades http:// to https://. For a site that serves only HTTP, the result is just

connect ECONNREFUSED 210.146.64.8:443

Nothing says that the request went to port 443 because of the upgrade, or that the site answers on plain HTTP. The model reads it as "the site is down" and either gives up or goes around WebFetch with curl through Bash, which skips WebFetch's own handling (charset decoding, size limits, the domain check).

HTTP-only sites are still common among older Japanese pages: project sites, university and personal pages, mirrors.

What Should Happen?

Either fall back to HTTP when the HTTPS connection is refused, or say so in the error, for example: http://openlab.jp/ was upgraded to https:// and the site refused the HTTPS connection; it may serve HTTP only.

Steps to Reproduce

1. WebFetch http://openlab.jp/ → connect ECONNREFUSED 210.146.64.8:443
2. WebFetch http://www.namazu.org/ → connect ECONNREFUSED 153.127.15.143:443

Controls from the same machine:

$ curl -s -o /dev/null -w "%{http_code}" http://openlab.jp/     # 200, page reads fine
$ curl -s -o /dev/null -w "%{http_code}" https://openlab.jp/    # 000, connection refused

Environment

• Claude Code 2.1.295 (Claude Desktop's Code tab), Windows 11
• WebFetch called directly