Django同项目跨应用API请求本地正常部署后调用失败问题

本地运行正常、正式部署后同项目API调用失败，核心问题出在你构造API地址的逻辑：request.build_absolute_uri(reverse('create')) 完全依赖当前请求的Host头、协议头拼接绝对路径，正式部署环境只要存在反向代理、HTTPS卸载、端口映射、CDN接入等配置，就很容易拼接出错误的地址，常见错误包括：

• 拼出Nginx回源用的内网地址（如127.0.0.1:8000、容器内部服务名），服务内部请求时路由不通
• 正式环境启用HTTPS但Django未感知代理的协议头，拼出http://开头的地址，触发强制HTTPS跳转，POST请求跳转时会丢失请求体
• 反向代理未正确转发Host头，拼出错误的域名
• 服务器防火墙/安全组拦截了自身公网IP的出站请求

额外注意：同项目内的逻辑完全没必要发起HTTP请求绕一圈，既增加网络开销，也额外引入了网络故障点，单线程WSGI服务下还可能触发请求死锁，稳定性很差。

最优方案：直接复用接口逻辑，跳过HTTP请求 #

你要调用的create接口本身就是同项目内的代码，不需要走HTTP协议调用，直接复用对应逻辑即可，完全避免URL构造、网络连通性、认证相关的问题。
如果你的create接口是DRF的创建视图，直接调用对应序列化器完成创建即可，示例逻辑：

from datetime import date
from rest_framework.exceptions import ValidationError

def getpk(request, pk):
    current_user = request.user
    obj = LetterBody.objects.get(id=pk)
    if obj.reference_code:
        return redirect('letters')
    
    company = obj.company_details.short_code
    location = obj.company_details.location.short_code
    current_date = str(date.today())

    # 直接复用create接口对应的序列化器逻辑，不需要发HTTP请求
    payload = {
        'company':company,
        'location':location,
        'date':current_date
    }
    # 替换为create接口实际使用的序列化器类
    serializer = YourCreateSerializer(data=payload, context={'request': request})
    try:
        serializer.is_valid(raise_exception=True)
        created_obj = serializer.save()
    except ValidationError as e:
        # 按需处理参数校验错误
        raise e
    
    objid = created_obj.id
    obj.reference_code = f"{location}/{company}/{current_date}/{objid}"
    obj.save()
    return redirect('letter_detail', obj.id)

这种方式性能最好、稳定性最高，完全不受部署环境的网络配置影响。

备选方案：固定API根地址，避免动态拼接 #

如果暂时不方便重构逻辑、必须走HTTP请求，就不要依赖build_absolute_uri动态拼地址，在配置中固定内部访问的根路径：

1. 在项目settings.py中添加配置：

# 本地开发环境配置
INTERNAL_API_BASE = "http://127.0.0.1:8000"
# 正式环境通过环境变量覆盖为服务实际监听的内网回源地址，不要用公网域名

2. 修改代码中URL构造的逻辑：

from django.conf import settings

# 替换原有的build_absolute_uri逻辑
url = f"{settings.INTERNAL_API_BASE}{reverse('create')}"

3. 如果正式环境用反向代理+HTTPS，需要在settings.py中添加如下配置，让Django正确识别代理转发的协议头：

USE_X_FORWARDED_HOST = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

同时确保Nginx反向代理配置中添加了对应的头转发规则：

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

如果修改后还是调用失败，可以先把代码中构造出来的url打印到服务日志中，确认正式环境下拼接出来的地址是否可以在服务器本地通过curl命令正常访问，优先排查地址错误、网络连通性问题。

内容的提问来源于stack exchange，提问作者Emmanuel Njuguna