Odoo 19版 odoo.conf 配置参数概览

Odoo 19 的 odoo.conf 配置文件包含大量参数，可以用于调整 Odoo 系统在社区版和企业版中的行为，包括性能优化、安全加强和功能定制等。下面按照功能模块对所有主要配置参数进行分类列举，每个参数包含名称、功能说明、默认值及适用范围（社区版/企业版/通用）。此外，文末总结生产环境中推荐的配置及最佳实践建议。

数据库相关配置

参数名	功能说明	默认值	适用范围
db_host	指定 PostgreSQL 数据库服务器主机地址。如果为空则表示使用本地主机：在 Windows 下默认为 localhost，在类 Unix 系统上默认通过 UNIX 套接字连接。通常默认不设置（即本机）。	无（默认连接本机）	通用
db_port	指定数据库服务器端口，不设置时将使用 PostgreSQL 默认端口 5432。	无（默认为 5432）	通用
db_user	连接 PostgreSQL 数据库使用的用户名。默认不设置，需要根据实际数据库配置指定具有适当权限的用户。	无	通用
db_password	连接 PostgreSQL 数据库的密码。默认为空（无密码）。如数据库启用了密码验证，则必须在此设置。	无	通用
db_name	指定要连接的数据库名称。默认值为 False，不指定时将在登录界面列出可用数据库。一般在多数据库环境下可以用该参数限制只连接特定库。	False（未指定）	通用
db_maxconn	控制 Odoo 可以同时打开的 PostgreSQL 物理连接的最大数量。适用于高并发场景，防止耗尽数据库连接。默认值为 64。注意该限制是按进程（worker）应用的，每个 Odoo 进程最多建立该数量的连接。	64	通用
db_template	新建数据库时使用的模板数据库名称。默认使用 PostgreSQL 的 template0。	template0	通用
dbfilter	使用正则表达式过滤数据库，让 Odoo 仅显示或使用名称匹配特定模式的数据库。支持占位符%h（请求的主机名）和%d（请求的首个子域名）。多租户部署强烈建议设置此参数，以确保根据访问域名选取正确的数据库。	无（默认不过滤）	通用
db_replica_host	（新增）用于指定只读副本数据库服务器的主机地址。如果设置了该参数，部分读取操作可由副本数据库承担。未设置（为空）则不启用。	无（未启用）	通用
db_replica_port	指定副本数据库服务器的端口号。如果未设置则默认使用 db_port 的端口。	默认为 db_port 相同	通用
db_sslmode	指定 Odoo 连接 PostgreSQL 时的 SSL 模式，可选值包括 disable、allow、prefer、require、verify-ca、verify-full。默认值为 prefer，表示若数据库支持则尽量使用加密连接。在生产环境下建议根据需要设置为更严格的模式（如require）确保数据库连接安全。	prefer	通用
unaccent	布尔值，创建新数据库时是否尝试启用 PostgreSQL 的 unaccent 扩展（用于不区分重音符号的全文搜索）。默认值为 False（不启用）。	False	通用
pg_path	指定 PostgreSQL 二进制可执行文件所在路径。当使用数据库管理功能（例如数据库备份/恢复）且 PostgreSQL 安装在非标准路径时需要配置此项。默认不设置，此时使用系统环境中的 pg_dump 等工具。	无	通用
admin_passwd	设置数据库管理界面的管理员主密码。Odoo 使用该密码来保护数据库创建、备份、删除等管理操作接口。默认值若未在配置文件中指定则通常为 “admin”（出于安全应更改）。当通过界面修改时，将以哈希形式存储在配置文件中。强烈建议在生产环境将其设置为复杂的随机密码。	无（默认为 “admin”）	通用
list_db	控制数据库列表是否可见。如果设置为 False，将隐藏Web登录界面的数据库下拉列表并禁止未经授权的数据库管理访问（等价于启动参数--no-database-list）。默认值为 True（允许列出数据库）。在多租户或对外开放的服务器上建议设为 False 以增强安全。	True	通用

注：以上数据库参数适用于所有版本的 Odoo，无论社区版还是企业版。企业版仅在应用模块层面增加功能，不涉及不同的基础数据库配置参数。

服务与网络配置

参数名	功能说明	默认值	适用范围
http_interface	指定 Odoo 内置 HTTP 服务监听的网络接口IP地址。如设为空字符串则监听所有可用网络接口（0.0.0.0）。默认值为空（监听所有地址）。	空（所有接口）	通用
http_port	Odoo HTTP 服务监听端口。默认端口为 8069。可以修改此端口以避开冲突或满足特殊部署需求（例如同一服务器运行多个服务）。	8069	通用
http_enable	布尔值，控制是否启用HTTP服务。设置为 False 可不启动HTTP及长轮询服务（只运行cron等）。默认值为 True（启用HTTP）。注意：大多数场景应保持开启，除非希望仅运行后台任务且不提供网页服务。	True	通用
longpolling_port（已弃用）更换为 gevent_port	长轮询(Long Polling)服务端口，用于聊天和实时通知等功能。在启用多进程模式或 gevent 模式时使用。默认值 8072。在线程模式下不使用此端口。	8072	通用
proxy_mode	布尔值，启用代理模式。当 Odoo 部署在反向代理（如 Nginx/Apache）之后时，应将此选项设为 True，以使 Odoo 正确处理代理转发的头信息（如 X-Forwarded-Host / X-Forwarded-For 等）。默认值为 False。仅在 Odoo 后端确实经过受信任的代理时才启用该参数。	False	通用
x_sendfile	布尔值，启用后，Odoo 在返回附件内容时将设置 X-Sendfile（Apache）或 X-Accel-Redirect（Nginx）头，以将静态文件传输的工作交给前置的 Web 服务器处理。这可以提高大文件下载的效率。默认值为 False。启用该功能需要配合Web服务器相应配置。	False	通用
secure（也称 https）	布尔值，是否直接通过 Odoo 内置服务器启用 HTTPS/SSL 支持。设置为 True 时需同时提供 SSL 证书和私钥文件路径。默认值为 False（Odoo 不直接提供 HTTPS，通常通过反向代理实现）。	False	通用
secure_cert_file	当 secure 为 True 时，指定 SSL 证书文件路径，用于加密 Odoo 的 HTTP 通信。	无	通用
secure_pkey_file	当 secure 为 True 时，指定 SSL 私钥文件路径。必须与证书文件匹配。	无	通用
addons_path	Addons（模块）目录的搜索路径列表。多个路径可用逗号分隔。指定后，Odoo 将按照顺序扫描这些目录以加载可用模块。默认包含 Odoo 自身的官方模块目录。如果需要加载自定义模块，可以在此添加路径。	Odoo 安装目录下自带 addons 路径	通用
server_wide_modules	逗号分隔的模块列表，表示服务器范围内预加载的模块（即对所有数据库启用）。默认值为 'web'，确保 Web 界面模块在所有数据库中可用。可根据需要添加其它模块，例如企业版常用模块，但一般不建议随意修改默认值。	web	通用
import_partial	文件路径，用于在大量数据导入时保存中间状态。当通过界面批量导入数据遇到异常中断时，可使用此文件断点续导。默认不设置（为空）。只有在需要导入大量数据且希望支持断点续导时才配置。	无	通用
pidfile	指定一个文件路径，Odoo 启动时会将其进程ID (PID) 写入该文件。通常用于系统服务管理，方便编写启动/停止脚本。默认不设置。Linux 上通过 init 脚本或 systemd 管理服务时一般用不到此配置（init 脚本可自行创建PID）。	无	通用
geoip_database (或 geoip_city_db)	指定GeoIP数据库文件的路径，通常用于定位网站访问者的地理位置。例如提供 MaxMind GeoLite2 City 数据库 .mmdb 文件路径。如果同时支持国家库，可用参数 geoip_country_db 指定国家数据库文件路径。默认不设置（部分 Odoo 功能将无法提供基于IP的地理信息）。	无	通用

注：以上网络配置同样适用于社区版和企业版。在企业版中，如 Live Chat 等功能涉及长轮询/实时通信，需要正确配置 longpolling_port 和代理转发。

性能与多进程配置

参数名	功能说明	默认值	适用范围
workers	指定启动的 HTTP 工作进程 数量（多进程模式）。如果设置为 0，则表示使用单线程模式运行（不启用多进程）。默认值为 0（开发/测试模式下的单进程）。在生产环境中通常根据CPU和并发需求将其设置为 >0 以启用多进程并行处理。	0	通用
max_cron_threads	专用于执行计划任务（cron）的工作线程/进程数。在线程模式下表示线程数，多进程模式下表示单独的进程数。默认值为 2（即使 workers=0 时也有两个线程处理计划任务）。一般保持默认即可，除非有大量并发的计划任务需要调整。	2	通用
limit_request	每个工作进程在被回收重启前可处理的最大请求数。该机制有助于防止内存泄漏等长期运行问题。默认值为 8192 个请求。达到限制后，进程会在当前请求完成后重启。可根据内存情况酌情调整（减小该值可更频繁重启以释放内存）。	8192	通用
limit_memory_soft	每个工作进程允许运行的虚拟内存软限制（字节数）。当进程占用内存超过该值时，当前请求处理完毕后进程将被回收重启。默认值约为 2048 MiB（2048×1024×1024 字节）。软限制用于在不中断请求的前提下控制内存占用。	2147483648 字节 (2 GiB)	通用
limit_memory_hard	每个工作进程的虚拟内存硬限制。一旦进程内存占用超过此值，将立即被杀死（不等待当前请求完成）。默认值约为 2560 MiB（2560×1024×1024 字节）。硬限制用于防止单个进程因内存过大而拖垮系统，应略高于软限制以避免频繁中断。	2684354560 字节 (2.5 GiB)	通用
limit_time_cpu	单个请求允许使用的CPU时间上限（秒）。如果一个请求在用户代码中消耗的 CPU 时间超过该秒数，工作进程将被终止。默认值为 60 秒。该限制防止单个请求占用过多CPU资源。	60	通用
limit_time_real	单个请求的真实时间上限（秒）。与 limit_time_cpu 不同，它包括等待外部资源（如SQL查询）的时间。如果请求的总耗时超过此值，进程将被终止。默认值为 120 秒。	120	通用
limit_time_real_cron	（可能已废弃）单个计划任务允许执行的最长实时时间（秒）。在旧版本中默认不限制（None/-1 表示不限，若未设置则等同于 limit_time_real）。Odoo 19 中计划任务执行超时时间通常通过此参数控制，如果需要可手动设置，例如 0 表示不限制。	默认为不限 (0 或未设置)	通用
limit_time_worker_cron	（新增）计划任务工作进程的生命周期软限制（秒）。若设置为非0，一个cron子进程运行超过该时间后将在空闲时重启，以释放资源。默认值 0 表示不启用该机制。可选在长时间运行的 Odoo 实例中设置一个较长的周期来定期重启cron进程。	0	通用
osv_memory_age_limit (已弃用)	已废弃参数：OpenERP早期版本用于控制 transient 模型记录（临时对象，如向导）的最大保留时间（小时）。已由 transient_age_limit 取代。	废弃	通用
osv_memory_count_limit (已弃用)	已废弃参数：用于控制 transient 模型记录保留的最大数量。已由 transient_count_limit 取代。	废弃	通用
transient_age_limit	控制 TransientModel（临时模型，例如向导）记录在数据库中保留的最长时间（小时，浮点数）。超过时间的临时数据会被清理。默认值为 1.0 小时。	1.0	通用
transient_count_limit	控制 TransientModel 在数据库中保留的最大记录数。超过数量的老旧临时记录会被清理。默认值为 False，表示不限制数量（仅根据时间限制）。	False	通用

说明： 上述性能参数有助于提高 Odoo 在多用户环境下的稳定性和效率。社区版与企业版在这部分参数上并无差异，但企业版可能由于启用了更多应用，需要根据实际负载更仔细地调整这些参数。

Odoo 的默认 workers = 0 模式是“多线程”模式。由于 Python 的全局解释器锁 (GIL)，它无法真正利用多核 CPU，因此绝对不适合生产环境。生产环境必须启用“多进程”模式 (workers > 0) 来实现并发处理和扩展性。

注意：多进程模式在 Windows 上不可用。

A. 最重要的参数：workers 的计算

workers 参数决定了 Odoo 启动多少个独立的 Python 进程来处理 HTTP 请求。错误地设置此值是导致性能不佳的最常见原因。

• 计算公式:

有两个关键公式，它们不是互斥的，而是必须同时使用：

1. 1. 用户容量 (所需容量): 1 个 worker 大约能支持 6 个并发活跃用户。
   2. CPU 容量 (最大容量): 服务器能支持的最大 worker 总数（包括 cron worker）受限于 CPU 核心数。
      • Workers_{Max} = (CPU Cores * 2) + 1

• 架构分析 (综合应用):

我们来看一个来自 Odoo 官方文档的例子：一个 4 核 CPU、需要支持 60 个并发用户的服务器。

1. 1. 计算所需容量:60 / 6 = 10
   2. 计算最大容量:4 * 2 + 1 = 9
   3. 分析: 结论是显而易见的：该服务器的 CPU (最多 9 个进程) 无法 满足其用户负载 (需要 10 个进程)。这是一个硬件配置不足的信号。如果强行将 workers 设置为 10，过多的进程将争抢有限的 CPU 资源，导致频繁的上下文切换，性能反而会下降。

• 最佳实践 (配置):
  1. 首先，为 cron 任务分配 worker。这些任务通常是资源密集型的，最好将它们串行化以避免互相干扰。

max_cron_threads = 1

(对于 16 核以上的大型服务器，可以考虑设置为 2 )。

1. 1. 然后，将剩余的 CPU 容量分配给 HTTP (用户) worker。

workers = 8; (9 max - 1 for cron = 8)

1. 1. 最终的生产公式是：
      • Total= (CPU Cores * 2) + 1
      • max_cron_threads = 1
      • workers = Total - max_cron_threads

B. 内存管理 (防止内存泄漏)

Odoo worker 进程可能会随着时间的推移而产生内存泄漏。配置内存限制可以强制进程在达到阈值时自动重启，释放内存，从而保持系统长期稳定。

• limit_memory_soft: “软”限制。当进程达到此限制时，它会完成当前正在处理的请求，然后优雅地重启。这是对抗内存泄漏的主要工具。
• limit_memory_hard: “硬”限制。当进程达到此限制时，它会立即被操作系统杀死。这是一个防止单个失控进程拖垮整台服务器的“紧急刹车”。
• 最佳实践 (设置值):
  • limit_memory_soft必须 设置得足够高，以允许运行合法的“重”请求（例如，复杂的库存报告或财务报表，可能需要 1GB 甚至更多的内存）。如果设置得太低（例如 1.5GB），这些重报告将永远无法完成，导致 worker 不断重启。
  • limit_memory_hard 应设置得比 soft 稍高，作为最后的安全网。
  • 推荐值:

limit_memory_soft = 2147483648; 2 GB  limit_memory_hard = 2684354560; 2.5 GB

• 架构分析 (总内存规划):

设置了 limit_memory_soft 后，必须确保服务器有足够的总 RAM。

• • 公式:RAM > ( (workers + max_cron_threads) * limit_memory_soft ) + RAM
  • 示例: 使用上面的配置 (8 workers + 1 cron) 和 2GB 的软限制：

RAM = (8 + 1) * 2GB = 18 GB

• • 这 18GB 仅仅是 Odoo 应用本身的内存需求。此外，PostgreSQL 数据库也需要大量内存（例如，shared_buffers 建议为总 RAM 的 25% ）。因此，要稳定运行此配置，一台 32GB RAM 的服务器是合理的起点。

C. Cron 任务调优

如前所述，max_cron_threads 应设置为 1 或 2，以防止 cron 任务（如计划的同步、备份、邮件发送）相互竞争并耗尽服务器资源。

• limit_time_real_cron:

此参数限制单个 cron 任务可以运行的最长“实时”时间（以秒为单位）2。默认值（例如 300 秒 / 5 分钟）对于许多大型作业（如数据导入或复杂的报告生成）来说太短了。

• • 最佳实践: 将此值设置得足够高，以允许大型夜间作业完成，但又能防止失控的作业永远运行。

limit_time_real_cron = 7200; 2 小时

D. 防止请求堆积 (超时限制)

• limit_request:

一个 worker 在自动重启（以回收内存）之前处理的请求数。默认值 8192 通常是合理的。

• limit_time_cpu:

单个请求允许消耗的 CPU 时间（秒）。这可以防止由于低效代码（例如笛卡尔积）导致的 CPU 100% 占用。默认值 60 适用于大多数情况。

• limit_time_real:

单个请求允许占用的总“实时”时间（秒）。这对于防止 worker 被慢速的外部 API 调用或死锁的事务所“挂起”至关重要。默认值 120（2 分钟）是合理的。

• • 最佳实践: 如果您有已知的、运行时间非常长的报告，您可能需要提高这些值，例如 limit_time_cpu = 600 和 limit_time_real = 1200。但更好的做法是优化这些报告，而不是盲目提高全局超时。

性能最佳实践：数据库连接与 PostgreSQL 调优

Odoo 的性能瓶颈几乎总是在数据库层面。odoo.conf 中的数据库设置必须与 PostgreSQL 服务器上的 postgresql.conf 设置协同工作。

A. 掌握 Odoo 连接池 (db_maxconn)

这是生产部署中最关键、最危险、也最容易被忽视的设置。

• db_maxconn: Odoo 每个进程的内部数据库连接池大小。默认值为 64。
• max_connections (PostgreSQL): PostgreSQL 服务器允许的总连接数。默认值通常为 100。
• 架构分析 (灾难场景):

让我们计算一下 Odoo 默认设置对数据库连接的“总需求”：

• • Odoo 进程总数 = workers + max_cron_threads + 1 (用于 longpolling/gevent) 。
  • 使用我们之前的生产配置：8 + 1 + 1 = 10 进程。
  • 总连接需求 = Total * db_maxconn
  • 10进程 * 64 默认 = 640 连接

结论: 您的 Odoo 应用（需要 640 个连接）将请求远超 PostgreSQL（只允许 100 个连接）所能提供的资源。在中等负载下，Odoo 将耗尽所有可用的数据库连接，导致服务器彻底崩溃，并在日志中充满 "FATAL: remaining connection slots are reserved..." 错误。

• 最佳实践 (解决方案):

默认的 db_maxconn = 64 仅适用于 workers = 0 的开发模式。在生产环境中，必须大幅降低它。

1. 1. 在 postgresql.conf 中: 适度增加 max_connections。不要设置得过高，因为每个连接都需要消耗 RAM。max_connections = 200 是一个合理的起点。
   2. 在 odoo.conf 中: 大幅降低 db_maxconn。
   3. 示例:200/(8 + 1 + 2) = 200/11 = 18
   4. 推荐配置:

db_maxconn = 18

(18 远比 64 安全和合理)。

B. postgresql.conf 推荐调优

Odoo 的性能直接依赖于 PostgreSQL 的内存和 I/O 配置。odoo.conf 调优必须辅以 postgresql.conf 调优。

以下是针对 Odoo 19 生产服务器的 postgresql.conf 关键参数推荐。分为“保守”和“激进”两种方案。“保守”方案适用于 Odoo 和 PostgreSQL 共享同一台服务器的RAM，“激进”方案适用于 PostgreSQL 拥有专用服务器。

参数 (postgresql.conf)	保守值 (共享服务器)	激进值 (专用服务器)	目的
max_connections	200	200	必须 大于等于Odoo 总需求。 (见上文分析)
shared_buffers	15- 20% of total RAM	25% of total RAM	PostgreSQL 的主要缓存，用于数据块。
effective_cache_size	50 - 70% of total RAM	75% of total RAM	告知查询规划器 OS 缓存的可用大小。
work_mem	16 MB - 64 MB	64 MB	每个排序/哈希操作的内存 (Odoo 报表常用)。
maintenance_work_mem	256 MB - 512 MB	256 MB	用于 VACUUM 和索引创建的内存。
checkpoint_completion_target	0.9	0.9	分散检查点 I/O，减少峰值负载。
checkpoint_timeout	15 - 30	15 - 30	降低检查点频率，减少 I/O 尖峰。
max_wal_size	2 GB	4 GB	允许 WAL 增长得更大，进一步减少检查点频率。

性能最佳实践：实施 Redis 缓存

为了进一步降低数据库负载并加快响应时间，Odoo 19 可以配置为使用 Redis（一个高性能的内存键值数据库）来存储会话 (sessions) 和缓存数据。

Odoo 19 的 Redis 配置比早期版本更加精细化，它区分为“会话存储”和“数据缓存” 。

• 架构优势: 将会话和缓存分离到不同的 Redis 数据库（例如 dbindex 0 和 1）是最佳实践。这允许您在需要时清除数据缓存 (DB 1)，而不会立即使所有已登录用户的会话失效 (DB 0)。

A. 配置 Redis 进行会话存储 (强烈推荐)

这将把用户的登录会话从文件系统（默认）移动到 Redis，速度更快，并且是在多服务器负载均衡环境中实现会话共享的必要条件。

[options]
session_store = redis
session_redis_host = 127.0.0.1
session_redis_port = 6379
session_redis_dbindex = 0
; session_redis_password = your_redis_password

B. 配置 Redis 进行数据缓存 (可选)

这会启用一个额外的缓存层，用于存储频繁查询的数据库结果。

[options]
enable_redis = True
redis_host = 127.0.0.1
redis_port = 6379
redis_dbindex = 1
; redis_password = your_redis_password

注意：旧的 cache_db = redis://... 语法 似乎已被 Odoo 19 中更精细的 enable_redis / redis_host 语法所取代或补充。

部署最佳实践：配置反向代理 (Nginx)

如前所述，生产中的 Odoo 必须在 Nginx 反向代理之后运行。

A. 必不可少的参数：proxy_mode = True

• proxy_mode: 此参数必须设置为 True 。
• 根本原因分析 (解决 localhost:8069 问题): 一个非常常见的问题是 Odoo 生成的 URL（例如在 sitemap.xml 或发送给客户的电子邮件链接中）错误地使用了内部地址，如 http://localhost:8069/... 。
  • 为什么会这样？ Nginx 正在向 Odoo 发送正确的 X-Forwarded-Host: your-domain.com 和 X-Forwarded-Proto: https 头部信息 。但是，默认情况下，Odoo 不信任 也 不读取 这些头部信息。
  • 解决方案: 将 proxy_mode = True 设置为 True 会告诉 Odoo：“您正位于代理之后，请信任并使用 X-Forwarded-* 头部信息来构建所有 URL”。这会立即修复所有 URL 生成问题，并确保 Odoo 日志记录的是真实的用户 IP，而不是 127.0.0.1 。

B. 配置 Longpolling (LiveChat 和通知)

Odoo 使用一个单独的、基于 gevent 的进程来处理实时通信（如 LiveChat、即时通知）。这需要 Nginx 进行特殊配置。

• Odoo 配置: 此进程的端口由 gevent_port (默认 8072) 定义 。注意：旧的 longpolling_port 参数已被弃用 。

gevent_port = 8072

• Nginx 配置: 您必须在 Nginx 中添加一个单独的 location 块，以将 /websocket/ (或 /longpolling/) 路径的请求转发到 gevent_port 。如果缺少此配置，LiveChat 和通知将失败或回退到效率低下的轮询。

C. Nginx 生产环境配置模板

为了将所有内容整合在一起，以下是一个生产就绪的 Nginx 配置文件（位于 /etc/nginx/sites-available/odoo.conf），它包含了 SSL、proxy_mode 头部、gevent 路由和安全加固。

# 定义两个 Odoo 上游服务器：一个用于常规 HTTP，一个用于 gevent (LiveChat)
upstream odoo {server 127.0.0.1:8069;
}
upstream odoochat {server 127.0.0.1:8072;
}# (可选) HTTP 到 HTTPS 的重定向
server {listen 80;server_name your-domain.com;return 301 https://$host$request_uri;
}# 主 HTTPS 服务器块
server {listen 443 ssl http2;server_name your-domain.com;# SSL 配置ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;ssl_session_timeout 1d;ssl_session_cache shared:SSL:10m;ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...';ssl_prefer_server_ciphers on;# 增加超时时间以支持 Odoo 的重报告proxy_read_timeout 1200s;proxy_connect_timeout 1200s;proxy_send_timeout 1200s;# Odoo proxy_mode 所需的头部信息 proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Real-IP $remote_addr;# 常规 HTTP 请求的代理location / {proxy_pass http://odoo;proxy_redirect off;}# LiveChat / Websocket 请求的代理 location /websocket/ {proxy_pass http://odoochat;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "Upgrade";proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-Proto $scheme;}# 静态文件的缓存location ~* /web/static/ {proxy_cache_valid 200 60m;proxy_buffering on;expires 864000;proxy_pass http://odoo;}# Gzip 压缩gzip on;gzip_types text/css text/plain text/xml application/xml application/javascript application/json;
}

日志配置

参数名	功能说明	默认值	适用范围
logfile	指定日志输出文件路径。设置该选项后，Odoo 的日志将写入指定文件，而非标准输出(stderr)。Unix 系统上建议配合系统日志轮转工具，以避免日志文件过大。默认不设置（日志输出到控制台）。	无	通用
log_level	全局日志级别。可选值有：debug, info, warning, error, critical 等，以及 Odoo 定义的组合级别如 debug_sql, debug_rpc, debug_rpc_answer 等。默认级别为 INFO。生产环境通常使用 INFO 或 WARNING 级别。	info	通用
log_handler	日志处理器配置，格式为 <日志记录器>:<级别>。可用来为特定模块设置不同的日志级别，例如 odoo.sql_db:DEBUG。默认值为 :INFO（即所有日志记录器默认INFO级别）。可以在配置文件中重复该项以配置多个日志记录器。	:INFO	通用
logrotate	布尔值，是否启用日志自动轮换。开启时，Odoo 将以每天一个文件的频率滚动日志，并保留最近30天的日志文件。默认值为 False（不自动轮转，由系统或管理员手动处理日志）。	False	通用
syslog	布尔值，是否将日志输出发送到操作系统的系统日志（如 Unix 的 syslog 或 Windows 的事件日志）。默认值为 False。启用后，logfile 设置将被忽略，因为日志将通过系统日志处理。	False	通用
log_db	布尔值，是否将日志写入数据库中的 ir_logging 表。默认值为 False。开启后，除常规日志外，还会在指定的数据库内记录日志，适用于集中日志管理或在Odoo界面中查看日志。通常需要配合 log_db_level 一起使用。	False	通用
log_db_level	当 log_db 启用时，指定写入数据库日志的级别过滤。可选值有：debug, info, warning, error, critical。默认值为 warning。例如设置为 info 则会将 INFO 及以上级别日志写入数据库。	warning	通用

安全配置

参数名	功能说明	默认值	适用范围
admin_passwd	（见“数据库相关配置”部分）数据库管理主密码，在此不再重复。
proxy_mode	（见“服务与网络配置”部分）代理模式，在此不再重复。
db_sslmode	（见“数据库相关配置”部分）数据库SSL模式，在此不再重复。
list_db	（见“数据库相关配置”部分）数据库列表开关，在此不再重复。
session_gc	控制过期会话的清理周期，单位为秒。默认值为 3600 秒（1小时）。Odoo 会周期性清理超过该时长未活动的会话，以释放内存并保持会话表干净。可以根据用户登录频率调整清理间隔。	3600	通用
secure/https	（见“服务与网络配置”部分）是否启用内置HTTPS，在此不再重复。

说明： 除上述参数外，安全性还依赖于部署架构和运维措施。Odoo 配置中的这些选项主要提供基础的访问控制和加密支持。社区版和企业版均需遵循安全最佳实践来配置这些参数。

邮件配置

参数名	功能说明	默认值	适用范围
smtp_server	SMTP 服务器地址。默认值为 localhost，表示使用本地主机的邮件服务器（如本地 Postfix 服务）。在使用外部邮件服务时需要将其改为相应SMTP主机地址。	localhost	通用
smtp_port	SMTP 服务端口。默认值为 25。若使用SSL加密（通常为465端口）或 STARTTLS（通常587端口），应相应调整端口号。	25	通用
smtp_user	用于SMTP身份验证的用户名。默认值为 False（不设置）。如果邮件服务器要求登录认证，则在此填写账号名。	False	通用
smtp_password	SMTP 身份验证密码。默认值为 False。需要与上述 smtp_user 搭配使用。	False	通用
smtp_ssl	布尔值，是否使用 SSL/TLS 加密与 SMTP 服务器通信（STARTTLS）。设置为 True 时，Odoo 会在发送邮件时启用 TLS加密。默认值为 False。	False	通用
smtp_ssl_certificate_filename	使用SSL认证时提供的证书文件路径（如果SMTP服务器需要客户端证书）。一般非必填，仅当SMTP服务要求双向证书校验时使用。默认值为空。	无	通用
smtp_ssl_private_key_filename	对应的SSL客户端证书私钥文件路径。仅在 SMTP 需要客户端证书认证时配置。默认值为空。	无	通用
email_from	Odoo 在发送邮件时使用的默认发件人地址。默认值为 False（即未设置默认地址）。通常在邮件模板中未指定发件人时会使用此地址。如果配置了 mail.catchall.domain 等系统参数，未匹配的发件人可能会被替换。	False	通用
from_filter	定义SMTP配置应用的发件人邮箱或域过滤器。可以指定一个邮箱地址或域名。如果一封邮件的发件人匹配此过滤器，则使用上述SMTP配置发送；否则将使用Odoo内部配置的mail.default.from和mail.catchall.domain进行封装转发。默认值为空（不过滤，所有邮件都直接使用SMTP配置）。	False	通用

开发与测试配置

参数名	功能说明	默认值	适用范围
dev (或 dev_mode)	开发者模式开关，可指定一系列开发辅助功能标志，以逗号分隔。如：all（启用所有开发选项），reload（检测Python文件变动自动重启），qweb（在 QWeb 模板中遇到 t-debug 时断点），werkzeug（在前端页面显示完整错误堆栈），xml（直接从XML文件加载QWeb模板而非数据库）等。不要在生产环境启用。默认情况下未启用任何开发选项。	False（空）	通用
test_enable	布尔值，启用单元测试模式。设为 True 时，在安装模块后自动运行其包含的测试（YAML/单元测试）。默认值为 False。通常仅在CI或调试测试时使用，不在生产中启用。	False	通用
test_file	指定要运行的测试文件路径（.py 或 .yml）。设置此参数将仅运行该测试文件。默认值为 False（不指定单独测试文件）。	False	通用
test_tags	指定测试标签过滤规则，仅运行与这些标签匹配的测试用例。语法为逗号分隔的 [-]<tag>[/module][:ClassName][.method] 列表，可用前缀-表示排除。例如：--test-tags :MyClass.test_func,/my_module。设置任意值即表示启用测试模式。默认值为空（不筛选测试）。	无	通用
test_report_directory	指定一个目录，将所有报告文档的样本输出保存到该目录（测试期间用）。默认值为 False（不保存报告文件）。	False	通用
test_commit	布尔值，在测试期间是否实际提交数据库事务。默认 False（即测试用例的任何数据库变更在结束时回滚）。只有在调试测试影响时才考虑开启，此时测试对数据库的更改会被保留。	False	通用
screenshots	指定当 JavaScript 测试（HttpCase）失败时保存截图的目录路径。默认路径为 /tmp/odoo_tests/<dbname>/screenshots。可修改路径以便调试前端测试。	/tmp/odoo_tests/<db>/screenshots	通用
screencasts	启用测试过程中录制屏幕录像，并指定录像文件保存目录。需要系统安装 ffmpeg 才能将帧编码为视频，否则仅保存截图帧。默认未指定（不启用录像）。	无	通用
stop_after_init	布尔值，在完成初始化（如安装模块或更新数据库）后立即停止服务器。适用于脚本化部署或迁移时，只想运行一次初始化任务。默认值 False。	False	通用
without_demo	控制加载演示数据。可以是布尔或列表/字符串：设为 True 或 'all' 表示在安装模块时不加载任何演示数据；也可指定逗号分隔的模块名列表以不加载这些模块的演示数据。默认值为 False（安装模块时如果有演示数据则加载）。在生产环境通常设置为 'all' 以避免部署示例数据。	False	通用
upgrade_path	指定额外的升级脚本目录路径，逗号分隔。当对模块进行迁移升级时，Odoo 将加载该目录中的迁移脚本。默认不设置。仅在需要执行自定义升级脚本时使用。	无	通用

生产环境推荐配置及最佳实践

配置正确的参数对 Odoo 部署的安全性和性能至关重要。以下是一些在生产环境中使用 Odoo 19 时的推荐配置和最佳实践：

• 安全：务必设置一个强随机的 admin_passwd 来保护数据库管理界面，防止他人未经授权创建或破坏数据库。启用多数据库的服务器应使用 dbfilter 将每个域名锁定到特定数据库，并结合 list_db = False 禁用数据库列表，以防止泄露数据库名和阻止未经许可的数据库创建操作。同时，建议通过防火墙限制数据库管理端口的访问，生产环境中尽量关闭.dump等不必要的功能。
• 网络/代理：如果 Odoo 后端部署在 Nginx/Apache 等反向代理后面，记得将 proxy_mode = True 打开，以便 Odoo 获取正确的客户端真实 IP 和协议信息。反向代理需配置相应的 X-Forwarded-* 头支持（例如在 Nginx 中使用 proxy_set_header X-Real-IP $remote_addr; 等）。此外，如使用 HTTPS，优先在代理处终结 SSL，再将流量转发给 Odoo；除非特殊需要，一般不推荐开启 Odoo 自带的 secure 模式。
• 性能/多进程：建议在生产环境使用 多进程模式（将 workers 设置为大于0的值），以更好地利用多核CPU并提供隔离容错能力。经验法则是每 6 个同时在线用户配置约 1 个 worker；或者按照 CPU 核心数，每核分配约 2 个 worker，再加 1 个额外 worker 作为上限（包括 cron 进程）。例如4核CPU的服务器，总 workers（含cron）不宜超过 4*2+1≈9 个。注意：如果仅使用单进程线程模式 (workers=0)，应将 threads 手动设为2以确保PDF报表等功能正常（一个线程处理请求，另一个线程提供静态文件服务）。但总体而言，生产环境强烈建议使用多进程以获得更高稳定性和性能。设置多进程后，Odoo会自动启动一个专门的长轮询(worker)用于实时功能，请确保相应端口和配置正确。
• 资源限制：根据服务器硬件资源调整 workers 和内存限制参数。确保 内存软/硬限制乘以 worker 数量不超过系统总内存，以避免 OOM（如默认每 worker ~2.5GB 上限，4 个 worker 大约需要10GB以上内存余量）。当有大并发或批量操作时，可适当增大 limit_request 让 worker 更频繁地重启，以清理资源。也可以通过监控调整 max_cron_threads，大批量后台任务可考虑将其提高到 3-4。数据库连接数 (db_maxconn) 默认64足以应对大部分场景，但如果部署了很多 worker 进程并发访问数据库，确保 PostgreSQL 的 max_connections 设置略高于 Odoo 可能的总连接需求（Odoo每个worker可打开多个连接）。例如有 8 个 worker，每个允许64连接，则 PG 至少需要 ≈8*64=512 连接上限（实际根据并发情况调优）。
• 日志和监控：将 log_level 保持在 INFO 或更高，以在生产中平衡性能和信息量。可以设置 logfile 将日志写入文件并使用 logrotate（或操作系统的日志轮转，如Linux上的logrotate）定期切分日志。建议保留最近30天的日志以便追溯问题。对于关键系统，可启用 syslog = True 将日志汇总到系统日志，配合集中日志管理。使用 log_db 将日志写入数据库一般不在高负载场景启用（除非需要通过Odoo界面审计日志）。同时，监控服务器CPU、内存使用率，保持在80%以下运行，以避免瓶颈。Cloudpepper等工具提供了对Odoo性能的监控，可以利用这些数据持续优化配置。
• 数据库优化：尽量将 Odoo 和 PostgreSQL 部署在同一局域网络内，减少延迟。生产环境中的 PostgreSQL 建议开启定期备份，并调优如工作内存、检查点等参数以配合 Odoo 负载。若数据库服务器独立并开启了远程访问，考虑将 db_sslmode 设为 require 以加密传输。此外，如果有大量读请求压力，可以利用 Odoo 19 新增的 只读副本功能：配置 db_replica_host（和端口）连接只读数据库，在参数层面Odoo会将某些读取操作路由到该副本，从而减轻主库压力。
• 其他：关闭未使用的功能以减少攻击面和资源占用。例如如果不需要 演示数据，安装时使用 without_demo = all 或确保配置文件中设置 without_demo，从而避免不必要的样例数据。admin_passwd 已设置后，可考虑在 Nginx 层面限制 /web/database/* 路径的访问，进一步保护数据库管理接口。对于邮件功能，使用专业的 SMTP 服务并在 Odoo 中正确配置 smtp_ssl 等参数，保障邮件发送可靠和安全。最后，定期更新 Odoo 版本以包含最新的性能改进和安全补丁，企业版用户还应确保相应的许可证和模块版本匹配以发挥最佳性能。

结论：Odoo 19 生产环境 odoo.conf 模板

以下是一个综合了本报告中所有最佳实践的生产环境 odoo.conf 模板。请根据您的服务器硬件（特别是 CPU 核心数）和数据库配置调整 __PLACEHOLDER__ 值。

[options]
; ===================================================================
; ODOO 19 生产环境配置模板
; 基于 Enterprise Systems Architect 最佳实践
; ===================================================================; === 1. 安全加固 ===
;
admin_passwd = __YOUR_RANDOMLY_GENERATED_PASSWORD__
;
; 必须设置：隐藏数据库管理器和列表
list_db = False
;
; 必须设置：将此实例锁定到单个数据库 (安全和功能需要)
dbfilter = ^__YOUR_PRODUCTION_DATABASE_NAME__$
;
; 必须设置：绑定到本地回环地址，由 Nginx 代理
http_interface = 127.0.0.1
;
; 推荐设置：如果数据库在远程主机上，请使用 require
db_sslmode = prefer; === 2. 性能 - WORKERS  ===
;
; 关键公式：(CPU_CORES * 2) + 1 = Total Processes
; 示例 (8 核 CPU): (8 * 2) + 1 = 17
;
; 串行化 cron 任务
max_cron_threads = 1
;
; 将剩余进程分配给 HTTP workers
workers = 16  ; (17 Total - 1 Cron = 16)
;
; 内存限制 (防止泄漏)
limit_memory_soft = 2147483648  ; 2 GB
limit_memory_hard = 2684354560  ; 2.5 GB
;
; 请求和超时限制 (适用于重报告)
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
;
; Cron 超时 (允许长时间的夜间作业)
limit_time_real_cron = 7200; === 3. 性能 - 数据库  ===
;
; 关键公式：floor( postgres_max_conn / (workers + max_cron_threads + 2) )
; 示例 (Postgres max_conn=200): floor( 200 / (16 + 1 + 2) ) = floor(200 / 19) = 10
;
; 必须调整以防止连接耗尽！
db_maxconn = 10
;
db_host = localhost
db_port = 5432
db_user = odoo
db_password = __YOUR_POSTGRES_PASSWORD__; === 4. 部署与运营  ===
;
; 必须设置：启用反向代理模式
proxy_mode = True
;
; 实时聊天/通知端口
gevent_port = 8072
;
; 运营：日志文件路径
logfile = /var/log/odoo/odoo-server.log
;
; 运营：日志级别 (使用现代 log_handler)
log_handler = :INFO
; log_handler = :WARN      ; (如果 INFO 太吵); === 5. 路径与杂项 ===
;
; Filestore (附件) 路径
data_dir = /opt/odoo/filestore
;
; 模块路径 (包含 Odoo 源码和自定义模块)
addons_path = /opt/odoo/odoo/addons, /opt/odoo/enterprise, /opt/odoo/custom_addons
;
; 在生产中绝不加载演示数据
without_demo = all; === 6. 缓存 ===
;
; (推荐) 启用 Redis 会话存储
; session_store = redis
; session_redis_host = 127.0.0.1
; session_redis_port = 6379
; session_redis_dbindex = 0
;
; (可选) 启用 Redis 数据缓存
; enable_redis = True
; redis_host = 127.0.0.1
; redis_port = 6379
; redis_dbindex = 1