Is Under Attack Mode enabled? (Edge section in your service settings)

I’d check what URL your OAuth discovery document is actually advertising for registration_endpoint.

If it’s returning something like:

http://your-domain/.../oauth/register

instead of https://..., that could explain the 405.

Railway redirects plain HTTP to HTTPS, and for POST requests that redirect can end up changing the request to GET. So the MCP client starts with a POST to the registration endpoint, Railway redirects it, and your app ultimately receives a GET on a POST-only route -> 405.

I’d check:

/.well-known/oauth-authorization-server

and look specifically at registration_endpoint.

It should be an https:// URL.

If your framework/library generates that URL from the incoming request, make sure it trusts Railway's forwarded proxy headers, or set the public/issuer/base URL explicitly to the HTTPS domain.

Then test the registration endpoint directly over HTTPS:

curl -i -X POST "https://YOUR_DOMAIN/oauth/register" \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "test-client",
    "redirect_uris": ["http://127.0.0.1/callback"]
  }'

If that works while the MCP client still gets a 405, I’d compare the exact registration_endpoint the client discovered against the URL above.

If the error is actually a 403 rather than a 405, I’d look at Railway's Edge/WAF settings instead, especially Under Attack Mode or any block/challenge rule on the OAuth paths.

Thanks for the tip! Under Attack Mode is off. But I found the cause: there is an Edge Rule on this service named "Block MCP OAuth register" (action: Block), which matches the /mcp-oauth/register path and returns the "Access denied" page. I'll review and adjust that rule and report back.

Thanks both! To close the loop: the registration_endpoint is already advertised over https, and the error is a 403 (not 405), so it is not an http-to-https redirect issue. Under Attack Mode is off. The cause is an Edge Rule on this service named "Block MCP OAuth register" (action: Block) that matches /mcp-oauth/register and returns the "Access denied" page. I'm going to review and adjust that rule and will report back here. Thank you for pointing me to the Edge settings!

Yep, that explains the 403 then.

Since that Edge Rule is explicitly blocking /mcp-oauth/register, the request is getting stopped before it ever reaches your OAuth server.

If you still need the registration endpoint available, I'd either remove/disable that rule or add a more specific allow rule above the broader block rule, depending on what you were originally trying to protect.

After changing it I'd just retry the same MCP OAuth flow. If the POST starts reaching the app but fails after that, then the next place I'd check would be the OAuth server logs/registration validation.

Glad you found it.