I would split this into two separate problems before changing more runtime settings.

First, the redis.railway.internal failure can be caused by the Redis client path, even when the private network itself is fine. With ioredis and BullMQ, make sure the Redis lookup is dual-stack instead of IPv4-only.

For direct ioredis usage:

import Redis from "ioredis";

const redisUrl = new URL(process.env.REDIS_URL);
redisUrl.searchParams.set("family", "0");

const redis = new Redis(redisUrl.toString());

For BullMQ:

import { Queue } from "bullmq";

const redisUrl = new URL(process.env.REDIS_URL);

const queue = new Queue("jobs", {
  connection: {
    family: 0,
    host: redisUrl.hostname,
    port: Number(redisUrl.port),
    username: redisUrl.username || undefined,
    password: redisUrl.password || undefined,
  },
});

That matters because private networking can involve IPv6, and ioredis can otherwise try only an A-record lookup.

Second, nameserver 192.168.1.1 inside the deployed container is not something I would try to fix with .dockerignore or preDeployCommand. /etc/resolv.conf is runtime/container-managed, and preDeployCommand runs before the final app process. If the deployed runtime really has your home-router address as its resolver, that is evidence to hand to Railway.

I would add one temporary diagnostic start command and redeploy once:

{
  "$schema": "https://railway.com/railway.schema.json",
  "deploy": {
    "startCommand": "/bin/sh -c 'echo RESOLV_CONF_START; cat /etc/resolv.conf; echo DNS_TEST_START; node scripts/dns-check.cjs; exec npm run start'"
  }
}

Then add this small script:

// scripts/dns-check.cjs
const dns = require("node:dns");

const hosts = [
  "redis.railway.internal",
  "maglev.proxy.rlwy.net",
];

for (const host of hosts) {
  dns.lookup(host, { all: true }, (err, addresses) => {
    console.log(host, err ? err.code || err.message : addresses);
  });
}

Check the deployment details after redeploy. If Railway shows that startCommand came from railway.json or railway.toml but the RESOLV_CONF_START log never appears, then the start-command override is the bug to report. If the log appears and still shows 192.168.1.1, then the runtime resolver is the bug to report.

For the public proxy, do not hardcode the resolved IP. Use the Railway-provided proxy hostname and port, or the generated public Redis URL if Railway gives you one. The proxy hostname is the stable interface. The underlying IPs can change, and hardcoding them will keep breaking.

The order I would use is:

1. Use the Redis service reference variable, preferably REDIS_URL, rather than a hand-written hostname.
2. Add family=0 for ioredis or family: 0 for BullMQ.
3. Confirm the app and Redis service are in the same Railway project and environment.
4. Add the temporary DNS diagnostic start command above.
5. If the deployed runtime still prints nameserver 192.168.1.1, open a Railway support ticket with that deploy ID and the DNS diagnostic logs.

The temporary fix should be family=0 plus the generated Railway Redis URL. The long-term fix, if 192.168.1.1 is confirmed inside the deployed runtime, needs Railway to look at why that resolver is being written into the container.