Your GemShopTrixBot deployment is crashing at startup because the Rubka client's token-validation request to the Rubika API fails, and the "no running event loop" error is raised by the library while it handles that failure, so both errors come from the same failed request rather than from your token variable.

We have no record of a platform fault affecting outbound traffic from this service. A timeout to one specific destination, while DNS resolution works, is most often the destination not answering traffic from that network, not a Railway egress problem. A host-level egress fault would make every outbound destination fail at once.

The check that tells these apart is running the same HTTPS test from your container against a different external host, such as any public API you know is up. If that succeeds while botapi.rubika.ir:443 still times out, the route out of Railway is working and the timeout comes from the Rubika side, which you would need to raise with Rubika. For help with the bot's own connection handling, you can post in our community.

I ran the requested comparison from the same Railway container.

https://example.com:

HTTPS_OK

STATUS: 200

TIME: 0.04 seconds

https://botapi.rubika.ir/v3:

HTTPS_FAILED

URLError:

So outbound HTTPS works from the container, but the Rubika API endpoint specifically times out.

Your comparison matches what our network records show for GemShopTrixBot: outbound traffic leaves the container normally, with zero dropped packets on any connection. The connections to example.com complete and exchange data. The connections to the Rubika API addresses send only a handful of small packets per attempt and never move any real data before your client gives up, so the Rubika side is not completing the connection with traffic from our network.

Since other destinations work over the same route, this is not an egress, routing, or firewall fault on our side, and redeploying or changing region will not change how the Rubika servers respond. Whether those servers accept connections from hosting-provider or non-Iranian networks is something only Rubika can confirm.

Thank you. I understand.

I will contact Rubika to ask whether their Bot API accepts HTTPS connections from Railway/cloud hosting or non-Iranian networks.

I will provide them with the connection timeout details.

Thank you. I understand.

I will contact Rubika to ask whether their Bot API accepts HTTPS connections from Railway/cloud hosting or non-Iranian networks.

I will provide them with the connection timeout details.