RefCheck doesn't ping. It speaks each protocol's own management handshake, from a fixed source IP, before deciding a reflector is unreachable. This page is a per-protocol checklist for what your reflector needs to accept -- and the two or three misconfigurations that cause most false-downs.
Digital voice software increasingly pulls its hostfiles pre-scrubbed by RefCheck -- reflectors that fail our probe are removed before the list ever reaches an end user's radio or hotspot. That's the entire point: nobody should waste a QSO attempt on a dead reflector. It also means a reflector that's actually online but misconfigured against the probe quietly disappears from the DV community's view, which helps nobody.
Every check below is a real, protocol-native control message -- the same class of packet your own client software would send to link or query the reflector. If your reflector answers a real client, the fixes here are almost always a firewall rule, an access-control list, or a software update, not a redesign.
A reflector's own operator is the only person who can fix why it's missing. Please don't post in WPSD, DVSwitch, or other downstream software's forums/groups asking "why isn't this reflector listed, please add it" -- that software doesn't generate its own hostfiles; it consumes RefCheck's already-scrubbed output, and its maintainers have no way to add anything back in.
Same goes for DVRef.com -- they're the upstream submission database RefCheck reads from, not the check that removes a listing. They can't control what RefCheck's probes decide.
If a reflector you use is missing, send this page to its operator. Once it passes the checks below, it reappears automatically at RefCheck's next sync -- everywhere, with no request needed.
For these four modes only, DVRef.com uses the RefCheck API to validate reflectors -- both when you first register one and on its own periodic re-checks. If RefCheck reports the reflector down, or the check times out (HTTP 408), DVRef will not pass it into its registry. That means the reflector never becomes available for any downstream consumer in the first place, not just RefCheck's own scrubbed hostfiles.
The check DVRef relies on is the identical one described below for your mode, so there's nothing separate to fix -- get your reflector answering the probe and both DVRef registration and RefCheck's hostfiles clear at once.
Four things are shared across all ten checks. Get these right first -- most single-protocol failures trace back to one of them.
Probes originate from 74.208.60.144. Don't null-route, rate-limit, or geo-block it -- some DDoS/flood shields silently drop the first unsolicited UDP packet from an unfamiliar IP, which looks identical to "reflector down."
Callsign RFCKRD0 (fallback W0CHP) for D-Star/YSF/M17/NXDN/P25/FCS checks; DMR ID 3226479 for DMR's subscriber ACL. XLX doesn't need whitelisting -- see the XLX note below.
Each protocol below is a specific management packet, not a ping. Reflector software that only relays voice traffic and never implements the poll/link opcode will never answer -- regardless of firewalling.
Each probe gets up to 3 attempts -- a 5-second timeout, then 2 retries. A reflector only needs to answer once in that window to be marked up; consistent multi-second lag across all 3 attempts is what reads as down.
No identity required -- the reflector's status beacon does the talking.
Port never reachable -- a firewall or NAT rule blocks inbound UDP on the port published in your hostfile entry, full stop.
Confirm UDP is open on that exact port from 74.208.60.144, not just from LAN/known client ranges.
Poll targets the same talkgroup published in the hostfile.
Hostfile TG doesn't match what the reflector is actually configured to answer on, so the poll lands on the wrong group.
Verify the TG in your published hostfile entry matches your reflector config exactly.
Single-byte opcode poll, same shape as NXDN's.
Same as NXDN: reflector software that never implements the poll opcode, only voice relay.
Update to a reflector build that answers 0xF0 polls (most DVSwitch/USRP-bridge stacks do out of the box).
The one protocol where an outdated reflector build is the single most common cause of a false-down. Covers both mrefd and urfd (URF) reflectors -- both speak the same LSTN handshake.
LSTN is a reflector-management poll, not a voice frame -- older M17 reflector daemons built before this was standardized never reply to it, even while happily passing real traffic between connected clients.
Update to a current mrefd / urfd build. If you're not sure your version supports LSTN, that's almost certainly why you're listed down.
A real repeater-login handshake -- and the one where "rejected" and "down" are easy to confuse.
Being rejected isn't what marks a reflector down -- an MSTNAK, or even silence after the salt exchange, still proves the reflector is alive. The failure is step 1 getting no RPTACK at all: some DMR master builds (HBlink/FreeDMR-family ACLs especially) silently drop RPTL from an unrecognized ID instead of NAK-ing it.
Confirm ID 3226479 is present in your subscriber/ACL database, and that your ID-database refresh job is actually running. A stale local copy that predates our ID is, by far, the most common DMR false-down we see.
Same RPTL/RPTK handshake as DMR above -- but on xlxd, this one isn't an ACL at all.
In xlxd's source, an incoming RPTL is only accepted once the DMR ID resolves to a callsign via the reflector's loaded ID directory (ccallsign.cpp: SetDmrid() → g_DmridDir.FindCallsign()). If 3226479 isn't in that directory yet, the resulting callsign fails validation and the packet is silently dropped -- no NAK, just a timeout. There's no separate DMR whitelist file involved for this check.
Nothing to whitelist. Just keep your DMR ID directory syncing -- whether that's xlxd's built-in default source or your own daily job pulling radioid.net's export. A running sync will already carry 3226479, since it's a real registered ID reserved for, and granted to, RefCheck's operator.
A two-stage handshake: a bare ping, then a full login.
DV019999Reflector answers the ping (proving it's alive) but never completes the login stage -- still reads down, since the ping alone isn't enough.
Make sure both stages are handled by the running daemon; a partially-hung ircDDBGateway/DPlus process is a common cause here.
Single poll packet targeting the module published in the hostfile.
Callsign-based access control silently discards the poll instead of replying with NAK.
Whitelist RFCKRD0 (or disable callsign gating for status polls specifically).
A full LINK request, same as any D-Star client would send to join a module.
Two reply formats exist in the wild (legacy and current DCS builds); reflector software stuck on a nonstandard third format won't be recognized.
A NAK is fine and still counts as up -- if you're seeing down, the LINK request itself is likely never reaching the daemon.
Host and port are derived from the room ID itself -- fcs001.xreflector.net:62500, no separate lookup.
One physical reflector hosts multiple rooms under one ID prefix -- if the reflector itself is down, every room under it goes down at once.
Confirm the base reflector process is running; room-level config rarely matters here.
A reachable-but-rejecting reflector (NAK, MSTNAK, BUSY) is treated as up by every check above. If you're seeing down, the packet almost never reached your reflector daemon at all -- look at firewalls, DDoS/flood protection, and ID/callsign ACLs before touching reflector config.
Every check above is exposed as a live API call -- the exact one RefCheck runs on its own schedule. Create a free access token -- self-service, a valid callsign is all it takes -- then query your own reflector directly, as many times as you need, until it comes back up: