“Name or service not known” points to a name-resolution/input-parsing failure, but the message alone doesn't identify which connection your bot is trying to make. Eleven copies could just be repeated attempts at the same failing call; they don't establish eleven separate faults or a Railway outage.

For example, Linux/glibc uses that text for EAI_NONAME: the host or service/port can be the problem (here “service” means the network service/port, not your Railway service name) (source, getaddrinfo reference). I checked the ambiguity locally: with numeric-only resolver flags, both a URL passed as a host and a nonnumeric service produce this same error; a valid numeric host/port succeeds. Those are local input-validation controls, not a reproduction of your bot or Railway DNS.

The next useful evidence is the first error, before the restart repetitions: your bot's language/runtime, the exception type/error code, and the library/function where it occurs. Share only a short sanitized excerpt—remove connection URLs, tokens, passwords, request headers and personal file paths. Also say whether that failing connection targets the bot platform, a database, or a proxy, and whether its hostname is public or ends in .railway.internal; no full connection string is needed.

If that call accepts host and port separately, check that its host input is only a hostname/IP, not https://…, a URL path or an unresolved placeholder. Don't strip the scheme from a setting whose API expects a full URL. The call site determines which format is correct. Once we identify the failing call, we can distinguish a malformed setting, private-network scope and an actual DNS failure without guessing changes to your deployment.