I am switching from http:// to https:// via Cloudflare proxies, but now I can’t connect to my servers (Sven Co-op and OTTD) .
What I found, that for accessing my Team Speak 3 server I set SRV record for 9987 port and now I can connect with same URL aso for the https:// website.
But for the others (Sven Co-op and OTTD) I still can’t connect even if I created records for these servers (Sven using TCP and UDP port 27015 and UDP 26900 - OTTD using TCP and UDP 3979) .
I think, that issue is in Service name for these SRV. TS3 has _ts3 service name, but I don!t know, if other games (Sven Co-op and OTTD) have Service names too.
It’s not working through the proxy. Most likely, you created that SRV record pointing to a hostname that isn’t on Cloudflare. You’ll have to create them all that way, pointing to names that are in your DNS as .
A couple things. First, I just tried it, and if I create an SRV record like yours that points to a host, Cloudflare is synthesizing a hostname for it to point to instead of the proxied one. The synthesized hostname is not a valid DNS hostname, but it should work some of the time, depending on the client software. When it works it will bypass the Cloudflare proxy. This could explain why it worked.
However, I am unable to resolve your SRV record at all, which is a mystery because your screenshot looks fine.
So, if the TS3 works, other server should work too, but I need to find right Service names. Because Minecraft should work like TS3 too (with service name _minecraft ) . I think, that SRV make an exception for port what will be set.
@SGvagon As you can see from the dig results, Cloudflare basically unproxied your ts3 subdomain. It is the EXACT same thing as if you deleted the SRV record und unproxied the ts3 subdomain yourself.
If you want things to work, you can only proxy the record to your website. The records you use for other things really need to be unproxied.
SRV records are basically used if you run multiple services on the same domain but different IPs, or if your services use non-standard ports.
Whether an application supports this depends on the developer of the application. It seems “Sven Coop” and “OTTD” don’t support this.
I’d recommend you either don’t use Cloudflare if you are running services on the same hostname as your website, or switch your non-HTTP services to different hostnames (like sven.manhetn.info, as you did with ts3).
Setting up SSL for your website is really not complicated, you don’t need Cloudflare for just that.
Ok, so if Cloudflare unproxied my ts3.manhetn.info , why is still https:// ? I am happy with that now, but i don’t know, if this page is still more secure than http:// .
On the other server I created unproxy adresses ( s.sven.manhetn.info and s.ottd.manhetn.info ) and in vhost on Apache set redirect to proxies adresses (sven.manhetn.info and ottd.manhetn.info) .
It’s maybe complicated, but works now too.
And how do I set SSL myself without Cloudflare? For free too like here?
It didn’t, not for the HTTP requests. The SRV record is returning a synthetic hostname that starts with _dc-srv which is not proxied.
It is not. In fact it is considerably worse. You are telling visitors that they should trust the site to be secure, but you then send their information to your server in unencrypted plaintext.
Free, automated, trusted SSL certificates have been publicly available from Let’s Encrypt for roughly 7 years now. They have a community similar to this one that can help with questions or guidance.
You can also obtain free certificates from the Cloudflare Origin CA. They will not be recognized by a browser and are therefore not suitable for hostnames that require direct connections. They are recognized as trusted certificates by the Cloudflare proxy and can be used in conjuction with Full (Strict) mode to protect traffic between the Cloudflare proxy and your origin server.
If by allow you mean instructs and by this address you mean the synthetic hostname that starts with _dc-srv, then you understand correctly.
The proxy was never a solution for anything other HTTP services and even then, they still need certificates on the origin servers. There is a persistent misunderstanding in what the free SSL from Cloudflare actually provides. It isn’t a one-click end-to-end SSL deployment. The Cloudflare proxy offers additional security and performance enhancement to existing HTTPS traffic.
You don’t have to choose between Let’s Encrypt and Cloudflare. They are different tools that solve different needs. Plenty of people use both.
) doesn’t support those protocols (nor UDP at all). You’ll have to set the DNS entries to 
for those hosts.