多环境下含协议域名获取：HttpContext与配置文件方案选型咨询

一、修复HttpContext获取完整域名（含协议）的问题 #

HttpContext.Request.Host.Value本身只返回主机名，要拿到带协议的完整域名，有两种可靠方式：

1. 直接拼接协议与主机 #

通过IsSecureConnection判断当前请求的协议类型，再和主机名拼接：

var scheme = HttpContext.Request.IsSecureConnection ? "https://" : "http://";
var fullDomain = $"{scheme}{HttpContext.Request.Host.Value}";
string doSomething = string.Format("{0}/sendpayment/{1}", fullDomain, 100);

用字符串插值更简洁：

var fullDomain = $"{(HttpContext.Request.IsSecureConnection ? "https" : "http")}://{HttpContext.Request.Host.Value}";
string doSomething = $"{fullDomain}/sendpayment/{100}";

2. 用UriBuilder构建（适配复杂场景） #

如果需要处理端口号、特殊主机名等情况，UriBuilder能自动处理默认端口省略（比如HTTPS的443、HTTP的80不会出现在最终地址里）：

var uriBuilder = new UriBuilder
{
    Scheme = HttpContext.Request.IsSecureConnection ? Uri.UriSchemeHttps : Uri.UriSchemeHttp,
    Host = HttpContext.Request.Host.Host,
    Port = HttpContext.Request.Host.Port ?? (HttpContext.Request.IsSecureConnection ? 443 : 80)
};
var fullDomain = uriBuilder.Uri.AbsoluteUri.TrimEnd('/');
string doSomething = $"{fullDomain}/sendpayment/{100}";

二、两种方案的对比与选择 #

1. 自动获取方案（推荐） #

• 优势：不用手动维护多环境配置，避免部署时漏改配置的风险；自动适配当前环境的协议和主机名，适合动态部署场景。
• 注意点：如果是反向代理部署（比如Nginx、IIS ARR），要确保服务器传递X-Forwarded-Proto头，并且ASP.NET能正确读取这个头，否则IsSecureConnection可能误判为HTTP。另外，后台任务、定时作业这类没有HttpContext的场景，得 fallback 到配置文件。

2. 配置文件方案 #

• 适用场景：
  • 需要生成的域名和当前请求域名不一致时（比如跨域回调地址、CDN静态资源域名）；
  • 无HttpContext的非请求上下文场景（如后台服务）。
• 劣势：多环境配置需要手动维护，容易出现部署遗漏，增加运维成本。

三、混合方案（最优实践） #

结合两种方案，优先用自动获取，无HttpContext时读取配置：

public string GetFullDomain()
{
    if (HttpContext.Current != null)
    {
        var scheme = HttpContext.Current.Request.IsSecureConnection ? "https://" : "http://";
        return $"{scheme}{HttpContext.Current.Request.Host.Value}";
    }
    // 无请求上下文时读取配置
    return ConfigurationManager.ApplicationSettings["domain"];
}

内容的提问来源于stack exchange，提问作者He-Man