Connect Don't Starve Together Master and Caves shards
A Don't Starve Together world with forest and caves runs multiple dedicated server processes. Treat the Master and Caves shards as parts of one cluster while keeping their process identities and ports separate. A forest that accepts players does not prove that the caves process exists or can communicate with it.
Check the supported cluster layout
Klei's command-line guide describes a shared cluster.ini with a separate server.ini beneath each shard directory. Its two-level example uses the same cluster name with -shard Master and -shard Caves. Your hosting template may use different storage paths, so inspect its effective options before copying files into a guessed directory.
Use settings generated through Klei's supported server configuration workflow as your starting point. Keep the shared settings and each shard's local settings together. Do not overwrite an established world's configuration with a newly generated world just to repair a cave connection. Preserve the original files and saves before making an adjustment.
Compare identities and allocations
- Record the cluster name and storage root used by each process. Both should point to the intended cluster, with the appropriate separate shard directory. Ask support if your panel presents the shards as separate services or split servers.
- Download the shared configuration and each shard's settings. Inspect the current generated shard configuration as a pair, including its communication settings, without publishing passwords or tokens.
- Compare the assigned game ports with the effective startup values. Klei requires distinct listening ports for servers on the same machine and documents separate Steam-related ports as well. Use only allocations the panel assigns; request additional ones if needed.
- Stop both shards for configuration changes. Correct the specific mismatch you found and keep the rest of the established cluster unchanged.
- Start the cluster through its supported controls. Inspect both shard logs for successful startup and connection errors before asking players to travel.
Verify travel in both directions
Use a volunteer with expendable inventory to enter the caves through an ordinary world entrance and return to the forest. Record the time and outcome for both transitions. Inspect the logs from both shards around that time. A lobby listing or a successful direct connection to one process cannot establish that shard-to-shard travel works.
Watch resource use with both processes active. Klei warns that hosting forest and caves together needs more computing capacity. Avoid a large mod change during this test, since a mod error could resemble a travel problem. If only one player fails, collect their client error before changing the whole cluster.
Recover from an unsuccessful edit
Stop both processes and restore the saved configuration pair if travel regresses. Keep current world data and logs intact. Do not regenerate caves or delete a shard directory as a connection fix; that can replace part of an established world. Escalate with redacted startup options, allocated ports and both timed logs so support can inspect the actual communication path.
Related help and sources
Klei shard layout and port options; Klei forest and caves hosting guidance.