MarcosFRGames
New Member
- Messages
- 10
- Reaction score
- 0
- Points
- 1
I use an intermediary service on JustRunMy.APP (a Node.js backend) between Telegram and my x10Hosting site. The flow is:
1. Telegram sends a webhook to JustRunMy.APP.
2. JustRunMy.APP replies 200 OK to Telegram instantly so users aren’t kept waiting.
3. JustRunMy.APP then opens a connection to my x10Hosting site and keeps it alive while the x10Hosting script waits for slow external APIs to respond.
Because x10Hosting does not have flush() or ignore_user_abort enabled, the connection must stay open until the script finishes. From x10Hosting’s perspective, the requests from JustRunMy.APP’s IP are long-lived and repetitive, which likely triggered an automatic anti-abuse block. The IP of JustRunMy.APP is now blocked from accessing my x10Hosting site, but the site itself is still functional.
There’s no malicious intent — this is the only way to provide a responsive experience for Telegram users given the hosting limitations. Could you please unblock the IP or suggest an alternative that avoids triggering the block?
1. Telegram sends a webhook to JustRunMy.APP.
2. JustRunMy.APP replies 200 OK to Telegram instantly so users aren’t kept waiting.
3. JustRunMy.APP then opens a connection to my x10Hosting site and keeps it alive while the x10Hosting script waits for slow external APIs to respond.
Because x10Hosting does not have flush() or ignore_user_abort enabled, the connection must stay open until the script finishes. From x10Hosting’s perspective, the requests from JustRunMy.APP’s IP are long-lived and repetitive, which likely triggered an automatic anti-abuse block. The IP of JustRunMy.APP is now blocked from accessing my x10Hosting site, but the site itself is still functional.
There’s no malicious intent — this is the only way to provide a responsive experience for Telegram users given the hosting limitations. Could you please unblock the IP or suggest an alternative that avoids triggering the block?