Skip to content

Fix forcedHosts for Cloudflare proxy + SRV record.#1497

Closed
alchemyyy wants to merge 1 commit intoPaperMC:dev/3.0.0from
alchemyyy:dev/3.0.0
Closed

Fix forcedHosts for Cloudflare proxy + SRV record.#1497
alchemyyy wants to merge 1 commit intoPaperMC:dev/3.0.0from
alchemyyy:dev/3.0.0

Conversation

@alchemyyy
Copy link

@alchemyyy alchemyyy commented Jan 20, 2025

Quick little patch that lets forcedHosts work when things like Cloudflare add extra junk to the HostString as they pass it along.

This is cool because now I can have an A record proxied over Cloudflare and an accompanying minecraft SRV record, which is a nice bit of hardening for no work or cost against random HTTP scrapes as they will all return the Cloudflare IP.

I haven't tested this with any other services. Obvious enhancements would be letting this be configurable with something like a user defined regex parsing string defined in the toml since I've seen other users talking about similar issues with other services. I feel like another enhancement on this concept would be a debug option to print out the HostString to console, so people could figure out what's going wrong on their own.

@novitpw
Copy link

novitpw commented Jan 21, 2025

Show CloudFlare settings to reproduce this situation

@456dev
Copy link
Contributor

456dev commented Jan 21, 2025

kinda confirmed, but as a whole this seems like user error:

this occurs when the srv target A record has proxying (orange cloud) enabled

demo dns setup (velocity server itself will be offline when you read this
image

image

resultant records, as seen by mcsrvstat.us
image

the warning given in cloudflare's ui that this behaviour is occurring
image

vhost from velocities perspective with this setup
image

The true fix, is just using an SRV target that isnt proxied by cloudflare, rather than adding provider specific hacks into velocity itself.

additionally, as you can see above, this doesn't fully restore previous behaviour anyway:
with this patch, the vhost reported by velocity would be mc-srv-b-test.0456456.xyz, instead of the expected / true mc-srv-test.0456456.xyz, which is only known by cloudflare.

@electronicboy
Copy link
Member

having a means to diagnose vhost/forced host stuff is on the "would be nice but I have no idea how to cleanly pull it off" list;

But, yeah, this PR doesn't implement expected behaviour, it just cuts down on the noise of a DNS service provider-specific mangling to mitigate a specific misconfiguration manageable on their platform. CFs hack is nice in that it allows you to pretend that all is fine, but it's not really properly solving the issue here and just furthers the unexpected behaviour vs how the client works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants