Conan Exiles Enhanced Mods Fail After UE5 Upgrade

Freeze the modded database and evidence

1. 1Stop public joins and automatic restarts.
2. 2Use the available admin save path only if the world is still complete, then close normally; otherwise stop without writing more incomplete state.
3. 3Copy the whole ConanSandbox/Saved tree, including game_0.db sidecars, WindowsServer config, Mods, ModHttp.ini, and Logs.
4. 4Record the exact Enhanced build, mod order, original pak filenames, and the first failing log entry.

Reject Legacy-only assumptions

A UE4 mod that worked on Conan Exiles Legacy is not automatically compatible with Enhanced UE5. Check the mod publisher's current release and dependencies. If no Enhanced build exists, keep the production snapshot stopped or return to the compatible Legacy server rather than forcing the pak into Enhanced.

Restore expected pak names and load order

• Do not rename mod pak files; official troubleshooting identifies renamed paks as a load problem.
• Use the current Enhanced-compatible package and dependencies.
• Preserve the documented mod order, especially when one mod extends another.
• Test a vanilla/copy baseline before deciding that game_0.db is corrupt.

Treat ModHttp.ini as a security boundary

1. 1Read the current mod documentation and identify the exact origin it needs.
2. 2Add only that trusted origin to the mod's allowed set in ModHttp.ini.
3. 3Do not approve unknown origins or paste a permissive list from another server.
4. 4Restart privately and verify the required network feature without granting unrelated access.

Prove data-bearing mods before reopening

Join the copied world and inspect mod-owned structures, items, followers, recipes, and settings. Save, close normally, restart, and inspect again. If content is absent, restore the full pre-change Saved snapshot; do not let the incomplete world overwrite the only good database.

Use the failure stage to narrow the mod cause

A pak rejected before world load points first to package naming, Enhanced compatibility, corruption, or dependency order. A world that reaches play but lacks assets suggests the required mod did not load or the wrong database/mod list was selected. An HTTP-denied message identifies a specific origin request; it does not justify approving every origin or disabling the Mod HTTP boundary.

Keep a per-mod record of original pak filename, Enhanced release/version, dependencies, load order, required origins, and the first successful server build. After an official update, compare that record and test the smallest dependency group on a copied Saved tree. If the publisher has not confirmed Enhanced compatibility, the evidence-based choice is to wait or retain the matched earlier environment—not to relabel a Legacy mod as safe.

Branch on package, runtime, HTTP, or saved-data evidence

When the server rejects a pak before world initialization, compare its unmodified filename, publisher release, Enhanced compatibility, dependencies, and file integrity. When the pak is accepted but the first error names a missing class or dependency, preserve load order and test the smallest complete dependency chain on the copied Saved tree. A vanilla test that also fails moves the incident away from mods and toward the Enhanced build, configuration, or database.

When the world opens but content is absent, stop before saving and prove that the intended game_0.db and mod list were selected; a clean startup banner alone does not restore mod-owned objects. When the log reports an HTTP-origin denial, match the requested origin to the mod publisher's current documentation and allow only that exact trusted origin if required. An HTTP denial is not evidence that the pak is Legacy-compatible, and a working HTTP request is not evidence that persisted mod content survived.

Define conditions that forbid a public restart

For every stopped test, retain the first meaningful error, exact mod manifest, ModHttp.ini diff, Enhanced build, and Saved-tree snapshot. Roll back by replacing the entire isolated Saved tree with the pre-change copy while the process is stopped. If no compatible mod build exists, the safe choices are to keep the Enhanced copy offline or operate the matched Legacy environment—not to let players produce new writes in a world missing persisted content.

• Do not continue if a required data-bearing mod lacks a publisher-confirmed Enhanced build.
• Do not save if structures, inventories, followers, recipes, placeables, or settings owned by a required mod are missing.
• Do not approve a wildcard or unrelated web origin to silence Mod HTTP errors.
• Do not combine a new pak filename, dependency order, and database change in one test without an attributable checkpoint.

Verify and prevent mod-stack regressions

Test in layers: vanilla copied database only when safe, then foundational dependency paks, then dependent content paks, and finally each documented HTTP feature. For every layer, capture startup completion, first error-free load, one private join, representative mod-owned objects, administrator settings, save/normal close, and a second successful load. A layer passes only when both runtime behavior and persisted content remain intact.

Promote the stack with a signed-off manifest containing original pak names and hashes, publisher versions, Enhanced compatibility statements, dependencies, load order, exact allowed origins, server build, and last tested date. Before an Enhanced or mod update, take a stopped Saved-tree checkpoint and reproduce the matrix on a copy. Keeping ModHttp.ini changes reviewable and mod versions pinned to evidence turns the next failure into a bounded comparison rather than an unsafe permissions expansion.