Python web server works via IP but subdomain times out

Posted by user_t9mqsl in websites.

Hello Wispbyte Support, My Python aiohttp application is listening on 0.0.0.0:15351 and passes its local /health check. The public IP responds to HTTP requests, but my active subdomain foku6.wispbyte.app:15351 times out. Access through https://foku6.wispbyte.app shows "Web server isn't running". Server: FOKUS 6 TRADER Node: FREE EU RO 23 Support ID: 8c8a7f71 Could you please check the DNS, port routing and whether HTTPS reverse proxy is supported for my free server? Thank you.

Replies

Byte (AI assistant)

The subdomain routes to your server’s primary port . Try without ; adding the port bypasses the subdomain’s normal routing. 1. Check that is the primary port shown as your server’s Address. 2. If it isn’t, make aiohttp listen on that primary port, or change the primary port and recreate the subdomain. 3. If it is the primary port and the subdomain still shows “Web server isn’t running,” remove and recreate the subdomain, then try again. Subdomains are in beta; see Subdomains.

user_t9mqsl

Thank you for your help. I have now confirmed that the HTTPS reverse proxy works correctly. returns HTTP 200 OK through Cloudflare. The only remaining issue is the login form, which returns HTTP 403 with the error . Chrome DevTools shows: Origin: null Sec Fetch Site: same origin Host: foku6.wispbyte.app Request: POST /login The application currently rejects Origin: null. Could you confirm whether Wispbyte or Cloudflare modifies the Origin header, or whether this is entirely an application level issue? Thank you.

Byte (AI assistant)

is most likely coming from the browser, not being added by Wispbyte or Cloudflare. Browsers send it for opaque origin contexts such as a page opened from or a sandboxed iframe. doesn’t rule that out. 1. Open the login page directly at and submit from there—not from a local file, embedded sandbox, or different origin. 2. Check whether an iframe has a restrictive attribute or whether the form/script submits from an unexpected page. 3. Keep rejecting ; allow the exact expected HTTPS origin and use a CSRF token rather than broadly allowing arbitrary origins. If the page is loaded directly from that HTTPS address, check the browser’s Network details and your app’s request handling to find where the becomes .

Related discussions

Wispbyte Community Forum