DRF 输出的接口返回域名不对怎么办？按现象定位再修
先给结论：Django REST framework 返回的接口返回域名不对，不是序列化器算错了，而是它用来拼地址的那个请求对象里带的主机信息与真实访问地址不一致。绝大多数情况发生在反向代理后面——后端看到的是内网地址，于是拼出了内网域名。
新手常以为是字段配置写错了，反复改字段名却没效果。真正要查的是三件事：请求对象里的主机从哪来、是不是用了基于请求生成绝对地址的字段、有没有在没有请求的上下文里生成地址。
本文按现象给出定位顺序和对应的修法，并说明哪些改法只在特定环境生效。涉及框架行为的描述以通用实现为准，具体版本请对照自己项目的依赖版本。
先看结论
- 先看部署结构：反向代理后面必须让框架读到转发头，否则拼出来的一定是内网地址。
- 再看字段类型：接口返回域名由请求对象拼出，没有请求就会回落到配置里的默认值。
- 最后看历史数据：库里存的是绝对地址时，改配置毫无作用，只能改数据。
一、最小场景：地址是怎么拼出来的
把问题定死：接口返回一个详情地址字段，本地访问时正常，部署后返回的是内网域名。
这类字段通常长这样：
# serializers.py
from rest_framework import serializers
class ArticleSerializer(serializers.ModelSerializer):
url = serializers.HyperlinkedIdentityField(view_name='article-detail')
class Meta:
model = Article
fields = ['id', 'title', 'url']这段做的是用一个基于请求生成绝对地址的字段。它需要请求对象才能工作，请求对象来自序列化时的上下文。
# views.py
class ArticleViewSet(viewsets.ModelViewSet):
queryset = Article.objects.all()
serializer_class = ArticleSerializer这段用的是框架默认的视图集，它会在序列化时把请求塞进上下文。预期结果（未在本机执行）：返回的地址以本次请求的主机为前缀。
这个主机信息来自请求头。部署在反向代理后面时，后端收到的主机头往往不是浏览器访问的那个域名，于是接口返回域名就变成了内网地址。
二、按现象定位
接口返回域名不对可以按下面三种现象归类，对号入座最快。
2.1 部署后才不对，本地正常
基本可以确定是代理没有把原始主机传进来。让代理带上转发头，并在配置里声明要信任它：
# settings.py
USE_X_FORWARDED_HOST = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')这段做的是让框架优先读取转发头里的主机与协议。改完必须重启进程才会生效。
2.2 序列化器里手动拼的地址不对
手动调用 build_absolute_uri 时，地址完全取决于传入的请求对象。接口返回域名在异步任务或管理命令里最容易出错，因为那里根本没有请求，只能回落到配置里允许的第一个主机名。
修法是把真实域名作为配置项，在没有请求的场景下显式拼接，不要依赖请求对象。
2.3 改了配置还是不对
说明地址不是现算的，而是库里存的。查一下数据库字段里是不是躺着完整的绝对地址——这种历史数据改框架配置救不回来，只能写脚本把前缀替换掉。
Django 的基础配置可以对照 Django 教程 里的设置章节确认。
三、哪种修法适合你
| 现象 | 原因 | 修法 |
|---|---|---|
| 只有部署后不对 | 没读转发头 | 开启转发头信任 |
| 异步任务里生成的不对 | 没有请求对象 | 用配置项显式拼接 |
| 改了配置仍不对 | 库存的是绝对地址 | 迁移数据 |
| 只想拿相对路径 | 字段类型不合适 | 换成只返回路径的字段 |
选择依据是"地址是现算的还是存下来的"。现算的改配置，存下来的改数据，这一条分清了基本不会走弯路。数据迁移脚本的写法可以对照 Python 速查手册。
四、验证清单
4.1 先确认请求头
在视图里打印请求里的主机值，看是否与浏览器地址一致。不一致就先修代理。
4.2 区分现算与存储
临时把字段换成只返回路径的类型，如果地址立刻正常，说明问题出在拼装环节；如果仍然不对，就是数据问题。
4.3 别忘记重启
配置类改动在常驻进程里不会自动生效，改完必须重启。
4.4 验证清单
- 检查：打印请求里的主机值，确认与浏览器地址一致
- 运行：通过代理访问接口，观察返回的接口返回域名
- 预期：地址前缀为对外域名，协议正确
- 失败：仍是内网地址，说明转发头没被信任
- 修复：开启转发头信任，并检查代理配置
- 验证：重启进程后再次访问，并跑一次异步任务生成的地址
总结
接口返回域名不对，本质是框架拿到的主机信息不是浏览器访问的那一个。按"请求头—字段类型—历史数据"三步排查，基本都能定位。
三条要点带走：
- 部署在代理后面必须让框架读到转发头，改完要重启进程；
- 没有请求对象的场景不要依赖请求拼地址，改用配置项；
- 库存的绝对地址改配置无效，只能迁移数据。
下一步建议把对外域名收进配置，并给拼装地址的地方加一条断言。语法细节可以对照 Python3 教程 再确认一遍。
常见问题
Q：本地正常，上线就不对，一定是代理的锅吗？
A：八成是。后端看到的主机头由代理决定，没有转发头时只能拿到内网地址。先打印主机值确认，再改配置。
Q：不想要绝对地址，只想返回路径怎么办？
A：换成只返回路径的字段类型，或者在序列化器里只取路径部分。相对路径在前后端分离部署时更省心。
Q：异步任务里怎么生成正确地址？
A：不要用请求对象。把对外域名作为配置项，在任务里显式拼接，这样也不依赖运行环境。
Q：改了配置为什么没生效？
A：常驻进程不会自动重载配置，改完要重启。另外确认改的是实际运行的那份配置文件。
Q：接口返回域名在测试环境正常，生产就不对怎么办？
A：两个环境的代理配置不一致，生产没有把原始主机传进来。对比两边的转发头配置，通常是生产漏了协议头。
Q：历史数据里的地址怎么批量修？
A：写一次性迁移脚本，把旧域名前缀替换成新前缀。先在测试库跑一遍再上生产，并保留回滚手段。
延伸学习
想把这个知识点补扎实，可以按这个顺序来：
- 想系统补 Python 基础，Python 零基础到高薪就业 可以跟一遍；
- 读一篇相关笔记 Django 开发 RESTful API，看别人踩过的坑；
- 想随手验证一段代码，用 Python 在线运行 跑一遍最快。