-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to resolve backend... again #320
Comments
Don't include the null delimited bit |
I had tried that as well to no avail, adding that bit was post the pseudo-services.lan not working. I verified again, just to be sure, and got these logs:
I also figured out the domain issue with another server host, but the fix to get that goin doesn't seem to connect here either still. |
If you need further help please provide the latest config and debug logs. |
The latest debug logs I posted already, however here's my latest config if I'm understanding your request correctly
|
Idk why it defaulted with closing with comment, but fixed that, apologies. |
Now you have a different issue where you don't have a "forge" container that can be resolved
|
As in the forge container isn't running in a way that the router can contact? No, it might have something to do with that lookup forge isn't it? I'm checking into what might be causing the different IP # |
Correct
|
I'm looking into it further, and realized I don't know why it would be looking on that IP. Is there anything in the router container to point to the router hardware? |
That IP address could be Docker's DNS for container/service resolution. It means the forge container isn't running or is not resolvable within that container network. Or your docker networking is now not setup correctly. |
Wait, is the "forge.example.com=forge:25565" then saying, "[insert_domain_here]=[insert_network_here]:[insert_port_here]?" |
I don't know what that's saying or what you're asking exactly. I thought you manually redacted the values. I'm not sure if I can help any further since your problem scenario keeps changing. Does looking at this again help answer your question? |
That's fine, just verified it myself, and I can connect via IP now. For clarification, I was curious if the format for the mapping line in the compose file was the domain that connects to the server is to point to the network the server is running on and its port, so in this case I needed to change the network of the server to forge rather than what it was on, bridge.
Either way, TL;DR, updating the network the server was connected to was what was needed. I do thank you for your help! |
Hey there, I'm trying to get my domain to work with the server, and am facing the unresolved backend issue others on here have faced. I've gone through and verified my situation doesn't seem to match any previously by verifying my domain was not the example and it was matching (it wasn't, though it seems to be pointing to the proxmox hosting the container this is in, so might not be related in issue), nor is tied to SRV (it may have been at first, though after deleting srv record, problem persists). I have applied true to DEBUG, and this is what I'm facing:
My docker compose is as follows
The domain people are supposed to connect with is dungeons.pseudoservices.com, however due to the logs saying it couldn't find a backend for pseudo-services.lan, tried that as well as the extra bits past the backslash. I also use CasaOS on an Ubuntu 23.04 containerized server via Proxmox if that helps. This is also occurring via connection via IP and not domain, domain seems to have a different issue, though I wanna toy with this first.
The text was updated successfully, but these errors were encountered: