XMRig Configuration

Two ways to configure the same thing

Every setting exists twice: as a key in config.json and as a command-line switch. The file wins for anything permanent because it survives restarts and can be copied between machines; switches are convenient for a quick test. When both are present, the command line overrides the file for that run.

config.json at a glance

The file is ordinary JSON, so a stray comma or a missing brace stops the miner before it starts. Only a handful of blocks matter to a typical Windows user:

Block	Controls
pools	Pool address, port, wallet or worker name, TLS, failover order.
cpu	Whether the CPU backend runs, thread count, affinity, priority.
randomx	Memory mode, 1 GB pages, MSR tuning, NUMA behaviour.
http	Optional local API used by monitoring tools.
Top-level flags	Logging, background, donate level, retries, print interval.

A minimal working file is short:

{
  "autosave": true,
  "cpu": true,
  "opencl": false,
  "cuda": false,
  "pools": [
    {
      "url": "pool.example.com:3333",
      "user": "YOUR_WALLET_ADDRESS",
      "pass": "worker1",
      "keepalive": true,
      "tls": false
    }
  ]
}

With autosave enabled, the miner rewrites the file on first run and fills in every option it detected, which makes it a useful starting point for further edits.

Command-line options in brief

xmrig.exe -o pool.example.com:3333 -u WALLET -p worker1 -k
xmrig.exe -c alternative.json
xmrig.exe --threads=6 --cpu-priority=2
xmrig.exe --print-time=60 --log-file=xmrig.log

The full list is long; the command-line guide covers the ones that earn their place.

CPU settings

Threads

Auto-detection is a reasonable baseline, not an optimum. RandomX is limited by L3 cache, so on many processors the best result comes from fewer threads than the CPU exposes. Change one variable at a time and compare fifteen-minute averages.

Affinity

Pinning threads to specific cores keeps a thread on the cache slice it warmed up, and lets you deliberately leave a core or two free so the desktop stays responsive.

Huge pages

Large memory pages reduce translation overhead for the RandomX dataset and typically produce the biggest single improvement. On Windows they need administrator rights; 1 GB pages additionally need the right CPU and enough contiguous memory. If the startup log reports large pages as unavailable, fix that before tuning anything else.

Memory mode

Fast mode allocates the full dataset — about 2.5 GB per thread — and is what you want. Light mode fits in a fraction of the memory and runs many times slower; it is a fallback, not a setting to leave in place.

Pool settings

Use the pool's documented host and port, and match the TLS flag to the port you chose — a TLS port without "tls": true simply fails to connect. Keepalive prevents idle disconnects. Listing a second pool gives you automatic failover; the miner tries them in order. Worker names help only you, in the pool's dashboard.

Logging

Raise print-time so the log is readable, set log-file if you want a record to look at later, and use colors as you prefer. Verbose logging is for diagnosing a specific problem, not for everyday running.

Windows startup

To start mining with the machine, create a scheduled task that runs the executable from its own folder, rather than dropping a shortcut in the Startup folder — a task can run with the highest privileges, which is what large pages require. Do not configure it with a working directory other than the miner's own, or the config file will not be found.

Frequent mistakes

• Invalid JSON after a manual edit — validate before blaming the miner.
• Wallet address pasted with a trailing space, or the wrong address format for the coin.
• TLS enabled on a non-TLS port, or vice versa.
• Maximum threads configured on a CPU whose cache cannot feed them.
• Running without administrator rights and then wondering why large pages are off.
• Editing one file while launching another with -c.

If something still will not start, work through troubleshooting.

Configuration questions

What is config.json?

XMRig's settings file, read from the miner's own folder at launch. It holds pool, CPU, memory and logging options.

Where is it stored?

Next to the executable. Nothing is written to the registry.

Can I use several configurations?

Yes. Keep multiple JSON files and select one with -c filename.json.