starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Dyndns based Steam game server monitoring #4174

New issue

Open

opened 2026-02-28 03:53:42 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-28 03:53:42 -05:00

Owner

Originally created by @sametcatakli on GitHub (Jun 18, 2025).

Description:

When monitoring a Steam game server with Kuma, I’m encountering an issue where using a domain name as the host doesn’t work properly. This is because Steam’s API uses the server’s public IP address, not the domain name, for health checks.

My context:

I have a dynamic IP, so I use a domain name (via dynamic DNS) to always point to my current IP.

When I enter the domain name in Kuma, the health check fails because Steam tries to use the domain name, not the resolved IP.

Expected behavior:

I would expect Kuma to resolve the domain name to its current IP and use that IP in the request.

🏷️ Feature Request Type

Other

🔖 Feature description

Please consider adding a feature that allows Kuma to resolve a domain name to its IP address and then use that IP when performing Steam server health checks.

Why this is useful:

Steam’s API works only with IPs, not domain names.

For users with dynamic IPs, using a static domain name is necessary.

This feature would make Kuma compatible with dynamic IP setups while still enabling Steam server monitoring.

✔️ Solution

Suggestion:

A checkbox or option like “Resolve domain to IP before request” could be added for relevant monitor types.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @sametcatakli on GitHub (Jun 18, 2025). ### 📑 I have found these related issues/pull requests Description: When monitoring a Steam game server with Kuma, I’m encountering an issue where using a domain name as the host doesn’t work properly. This is because Steam’s API uses the server’s public IP address, not the domain name, for health checks. My context: I have a dynamic IP, so I use a domain name (via dynamic DNS) to always point to my current IP. When I enter the domain name in Kuma, the health check fails because Steam tries to use the domain name, not the resolved IP. Expected behavior: I would expect Kuma to resolve the domain name to its current IP and use that IP in the request. ### 🏷️ Feature Request Type Other ### 🔖 Feature description Please consider adding a feature that allows Kuma to resolve a domain name to its IP address and then use that IP when performing Steam server health checks. Why this is useful: Steam’s API works only with IPs, not domain names. For users with dynamic IPs, using a static domain name is necessary. This feature would make Kuma compatible with dynamic IP setups while still enabling Steam server monitoring. ### ✔️ Solution Suggestion: A checkbox or option like “Resolve domain to IP before request” could be added for relevant monitor types. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:monitor

good first issue

labels

2026-02-28 03:53:42 -05:00

deekerman commented

2026-02-28 03:53:48 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 24, 2025):

The gamedig monitor currently works like this:

github.com/louislam/uptime-kuma@9976ef94af/server/model/monitor.js (L704-L718)

To add such an option (should be fairly simple) the following refactoring is needed as well (I don't want more mess in that file)

move all gamedig-related logic to a monitoring type => github.com/louislam/uptime-kuma@9976ef94af/server/monitor-types
create a testcase to ensure that there are no regressions in the "do a dns-resolution first" logic

@CommanderStorm commented on GitHub (Jun 24, 2025): The gamedig monitor currently works like this: https://github.com/louislam/uptime-kuma/blob/9976ef94af050f68945e1fc94620216ef3728756/server/model/monitor.js#L704-L718 To add such an option (should be fairly simple) the following refactoring is needed as well (I don't want more mess in that file) - move all gamedig-related logic to a monitoring type => https://github.com/louislam/uptime-kuma/tree/9976ef94af050f68945e1fc94620216ef3728756/server/monitor-types - create a testcase to ensure that there are no regressions in the "do a dns-resolution first" logic

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@mariogarridopt commented on GitHub (Jul 1, 2025):

create a testcase to ensure that there are no regressions in the "do a dns-resolution first" logic

Is this possible to test without a public domain -> IP game server that we can query?

@mariogarridopt commented on GitHub (Jul 1, 2025): > create a testcase to ensure that there are no regressions in the "do a dns-resolution first" logic Is this possible to test without a public domain -> IP game server that we can query?

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jul 1, 2025):

Either by mocking the part doing external communication or by finding a server which we can use in our testcases, yes

@CommanderStorm commented on GitHub (Jul 1, 2025): Either by mocking the part doing external communication or by finding a server which we can use in our testcases, yes

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@mariogarridopt commented on GitHub (Jul 4, 2025):

I'm trying to add a new test for this change on #5970 but every time I runnpm run test-backend I get this error:

> uptime-kuma@2.0.0-beta.3 test-backend
> cross-env TEST_BACKEND=1 node --test test/backend-test

node:internal/modules/cjs/loader:1252
  throw err;
  ^

Error: Cannot find module '/Users/myuser/uptime-kuma/test/backend-test'
    at Function._resolveFilename (node:internal/modules/cjs/loader:1249:15)
    at Function._load (node:internal/modules/cjs/loader:1075:27)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:170:5)
    at node:internal/main/run_main_module:36:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v22.10.0
✖ test/backend-test (50.275417ms)
  'test failed'

ℹ tests 1
ℹ suites 0
ℹ pass 0
ℹ fail 1
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 54.146417

✖ failing tests:

test at test/backend-test:1:1
✖ test/backend-test (50.275417ms)
  'test failed'

Do you see what I am doing wrong?

@mariogarridopt commented on GitHub (Jul 4, 2025): I'm trying to add a new test for this change on #5970 but every time I run`npm run test-backend` I get this error: ```bash > uptime-kuma@2.0.0-beta.3 test-backend > cross-env TEST_BACKEND=1 node --test test/backend-test node:internal/modules/cjs/loader:1252 throw err; ^ Error: Cannot find module '/Users/myuser/uptime-kuma/test/backend-test' at Function._resolveFilename (node:internal/modules/cjs/loader:1249:15) at Function._load (node:internal/modules/cjs/loader:1075:27) at TracingChannel.traceSync (node:diagnostics_channel:315:14) at wrapModuleLoad (node:internal/modules/cjs/loader:218:24) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:170:5) at node:internal/main/run_main_module:36:49 { code: 'MODULE_NOT_FOUND', requireStack: [] } Node.js v22.10.0 ✖ test/backend-test (50.275417ms) 'test failed' ℹ tests 1 ℹ suites 0 ℹ pass 0 ℹ fail 1 ℹ cancelled 0 ℹ skipped 0 ℹ todo 0 ℹ duration_ms 54.146417 ✖ failing tests: test at test/backend-test:1:1 ✖ test/backend-test (50.275417ms) 'test failed' ``` Do you see what I am doing wrong?

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@rezzorix commented on GitHub (Jul 8, 2025):

Whats the TTL of the A / AAAA record of the domain pointing to your steamserver?

Maybe it is set too long?
Have you tried setting it to 1 munute?

Ah damn, sorry didnt read properly… just saw now that uptime-kuma is not trying to resolve the IP.

But then simple other question… why not query the api directly with a https monitor with keyword?

@rezzorix commented on GitHub (Jul 8, 2025): Whats the TTL of the A / AAAA record of the domain pointing to your steamserver? Maybe it is set too long? Have you tried setting it to 1 munute? Ah damn, sorry didnt read properly… just saw now that uptime-kuma is not trying to resolve the IP. But then simple other question… why not query the api directly with a https monitor with keyword?

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@mariogarridopt commented on GitHub (Jul 18, 2025):

But then simple other question… why not query the api directly with a https monitor with keyword?

I think that's a good option if you are trying to do this kind of check.
But, I feel that this should work too, intuitively it should work, it shouldn't be a problem to resolve the IP before query.

@mariogarridopt commented on GitHub (Jul 18, 2025): > But then simple other question… why not query the api directly with a https monitor with keyword? I think that's a good option if you are trying to do this kind of check. But, I feel that this should work too, intuitively it should work, it shouldn't be a problem to resolve the IP before query.

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@louislam commented on GitHub (Nov 24, 2025):

Posted this message in https://github.com/louislam/uptime-kuma/pull/5970#issuecomment-3571049556, also post here.

Wait, I think #5934 is about the Steam monitor, it is not related to the Gamedig one.

Gamedig should be able to resolve hostname.

I think this pr is fixing the wrong place. Am I missing anything?

github.com/louislam/uptime-kuma@0eebe86f81/server/model/monitor.js (L660-L667)

@louislam commented on GitHub (Nov 24, 2025): Posted this message in https://github.com/louislam/uptime-kuma/pull/5970#issuecomment-3571049556, also post here. > Wait, I think #5934 is about the Steam monitor, it is not related to the Gamedig one. > > Gamedig should be able to resolve hostname. > > I think this pr is fixing the wrong place. Am I missing anything? > https://github.com/louislam/uptime-kuma/blob/0eebe86f81a16b488714a09dfc4fd3a53f938d11/server/model/monitor.js#L660-L667

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@quinnell commented on GitHub (Dec 29, 2025):

Recently encountered this issue as well on 2.0.2. Any hope of this making it into a release?

@quinnell commented on GitHub (Dec 29, 2025): Recently encountered this issue as well on 2.0.2. Any hope of this making it into a release?

deekerman commented

2026-02-28 03:53:49 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 29, 2025):

If a test is added, I’d be happy to accept your contribution to this PR.

Once the test is in place, we can merge it.

Without a test, I won’t merge this, as we have no way to ensure this continues to work in the future.

https://github.com/louislam/uptime-kuma/pull/5970#pullrequestreview-3053118065

@CommanderStorm commented on GitHub (Dec 29, 2025): If a test is added, I’d be happy to accept your contribution to this PR. Once the test is in place, we can merge it. Without a test, I won’t merge this, as we have no way to ensure this continues to work in the future. - https://github.com/louislam/uptime-kuma/pull/5970#pullrequestreview-3053118065