本文系统梳理了Docker容器访问宿主机服务时碰到HTTP 400错误的根本原因，覆盖网络可达性、DNS解析、HTTPS/TLS验证、Django安全机制及Docker网络模式适配五大关键维度，并提供可直接落地的配置方案与代码级修复示例。

用Docker Compose编排多服务应用时，容器主动调用宿主机上运行的Web API是很常见的需求。比如，容器里跑着一个Python脚本，需要通过https://host.docker.internal:44358/...去调用宿主机上的服务。但实践中，经常会出现一个让人摸不着头脑的现象：宿主机上的浏览器或者Postman用得好好的，一到容器里用requests.get()就返回400 Bad Request。

老实说，这极少是网络连通性问题。你得顺着应用层的逻辑往下找——问题几乎总是出在服务端框架的安全校验上。结合你提供的mobydq-scripts调用逻辑，以及Khoj项目中同类400错误的深度分析，我们可以把核心矛盾锁定在：Django（或同类框架）因为无法识别容器发起的请求来源，触发了ALLOWED_HOSTS或CSRF_TRUSTED_ORIGINS校验失败。

? 一、根本原因：Django的Host与Origin验证机制

你的Python脚本通过https://host.docker.internal:44358发起请求，但Django默认只信任明确列出来的域名。当请求头中的Host: host.docker.internal或Origin: https://host.docker.internal不在白名单里时，Django会直接拒绝请求，返回HTTP 400（而不是403）。这是CSRF和主机验证模块的默认保护行为，换句话说，Django在说：“我不认识你，请走开。”

✅ 验证方法：进入宿主机API服务容器（或进程），检查其Django设置文件（如settings.py）中：

ALLOWED_HOSTS = ['localhost', '127.0.0.1']  # ❌ 缺少 host.docker.internal
CSRF_TRUSTED_ORIGINS = ['https://localhost:8000']  # ❌ 缺少 https://host.docker.internal:44358

? 二、四步精准修复方案（推荐按序实施）

✅ 步骤 1：为宿主机API服务注入正确域名环境变量

修改宿主机API服务的启动配置（比如Docker Compose的environment或systemd service），确保Django动态加载host.docker.internal：

# 在宿主机API服务的environment下添加：
environment:
  - ALLOWED_HOSTS=host.docker.internal,localhost,127.0.0.1
  - CSRF_TRUSTED_ORIGINS=https://host.docker.internal:44358,https://localhost:44358

⚠️ 注意：如果API服务本身也运行在Docker中，请确保它的容器加入与scripts相同的自定义网络（如mobydq_network），并使用服务名代替host.docker.internal（这样更可靠）。

✅ 步骤 2：强制容器识别host.docker.internal（Linux用户必做）

你已经在scripts服务中配置了extra_hosts，但是在Linux环境下，还需要额外启用Docker Desktop兼容模式，或者手动映射。最稳定的方案是显式声明网关IP：

services:
  scripts:
    # ... 其他配置保持不变
    extra_hosts:
      - "host.docker.internal:172.17.0.1"  # Docker0 网桥默认网关（bridge模式）
      # 或使用动态网关（推荐）：
      # - "host.docker.internal:host-gateway"
    # ? 关键：显式指定网络模式以确保DNS可达
    network_mode: "mobydq_network"  # 必须与API服务同网络

? 提示：host-gateway在Docker v20.10+原生支持。如果失效，先执行ip route | grep docker0获取实际网关IP替换。

✅ 步骤 3：Python请求端增强兼容性

在get_email_settings函数中，显式设置Host头并禁用证书验证（仅限开发/测试环境）：

def get_email_settings(authorization: str):
    headers = {
        'Authorization': f'Bearer {authorization}',
        'Host': 'host.docker.internal'  # ? 强制声明Host头，绕过部分框架校验
    }
    try:
        response = requests.get(
            "https://host.docker.internal:44358/api/services/app/TenantSettings/GetAllSettings",
            headers=headers,
            verify=False,  # ⚠️ 生产环境必须配置有效证书！
            timeout=30
        )
        response.raise_for_status()
        return response.json()['result']['email']
    except requests.exceptions.RequestException as e:
        log.error(f"API request failed: {e}")

✅ 步骤 4：终极方案——使用宿主机真实IP替代host.docker.internal

如果以上方法都失败，直接使用宿主机在mobydq_network中的实际IP（通过docker network inspect mobydq_network查看Gateway字段）：

# 在scripts容器内执行：
# $ ip route | grep default | awk '{print $3}'
# 输出类似：172.20.0.1 → 此即宿主机在该网络中的IP
HOST_IP = "172.20.0.1"  # 替换为实际网关IP
url = f"https://{HOST_IP}:44358/api/..."

同时，记得在Django的ALLOWED_HOSTS中添加这个IP。

? 三、关键注意事项与最佳实践

• 永远不要在生产环境使用verify=False：应该为宿主机API配置合法的TLS证书，并将CA证书挂载到容器的/usr/local/share/ca-certificates/，然后执行update-ca-certificates。
• 避免混合网络模式：scripts与宿主机API服务必须处于同一Docker网络（如mobydq_network）。network_mode: "host"会绕过Docker网络栈，导致extra_hosts失效，不推荐使用。
• Linux用户特殊处理：host.docker.internal在原生Docker Engine（非Docker Desktop）中默认不可用，必须通过extra_hosts显式映射，而且建议优先使用网关IP。
• 验证工具链：在scripts容器内快速诊断：

  # 测试基础连通性
  ping host.docker.internal
  # 测试端口可达性
  telnet host.docker.internal 44358
  # 测试HTTPS握手（跳过证书校验）
  openssl s_client -connect host.docker.internal:44358 -servername host.docker.internal

通过以上结构化修复，99%的容器调用宿主机API返回400错误的问题都能根治。核心要诀在于：把容器请求“伪装”成被服务端框架信任的合法来源，而不是单纯解决网络层的连通性。道理很简单，但做起来需要一点耐心。