1. Introduction
A customer tells you, “I paid, but I still cannot browse.” That sentence does not tell you what is broken. It could be a typo in a voucher code, a credential that was already used, a mismatched setting on the router, a blocked path to the billing server, or a profile that hands out the wrong speed. MikroTik hotspot billing troubleshooting is the habit of linking what users see to the most likely failure type, then checking causes in a sensible order instead of changing settings at random.
This guide is for small hotspot operators and junior network administrators who run RADIUS billed WiFi on MikroTik RouterOS. RADIUS stands for Remote Authentication Dial-In User Service. In plain words, it is the conversation between your router and a central server: the router asks “may this user in?”, the server answers yes or no, and later the router reports how long the user stayed. Billing depends on both parts of that conversation working.
Most billing problems fall into recognizable groups: authentication entry issues, secret and client settings, service flags and login methods, firewall and connectivity blocks, accounting gaps, and profile and rate problems. This article walks through each group in the order I suggest you check them, starting with what the user sees and ending with what the router and server record. Along the way I will point out how logs and routine monitoring help you stop the same failure from coming back.
2. Mapping Symptoms to Billing Failure Types
Before you open any settings screen, sort the complaint. Users describe symptoms, not causes, so your first job is translation. A few simple questions do most of the sorting. Did the login page appear at all? Did the page accept the code but refuse access? Did access work for a while and then stop? Each answer points to a different family of failures, and keeping them apart saves you from fixing the wrong layer.
Write the report down in the user’s own words, note the device they used, and note whether other users were affected at the same time. A problem that hits everyone points toward the router, the server, or the path between them. A problem that hits one person points toward the code, the account, or that device.
2.1 No Login Page and No Redirect Behavior
When the login page never appears, voucher validity is not the issue yet. A voucher cannot be checked until the user reaches the page where it is entered. A MikroTik hotspot login page not redirecting points toward the Hotspot Server, DHCP behavior, or basic connectivity instead.
Start on the user side. Ask whether the device shows it is connected to the WiFi network and whether it received an address. A device that connects but never gets an address usually has a DHCP problem, which means the DHCP Server did not hand out the details the device needs. A device that has an address but sees no login page may have an old cached page, a browser that tries only secure sites, or a hotspot service that is not active on that network. Ask the user to open a plain, simple website address in the browser and report exactly what appears: nothing, a timeout, a certificate warning, or a login screen.
If several users report the same thing at the same moment, suspect the Hotspot Server or the DHCP Server on the router. If one device fails while others work, suspect that device first. This is the question behind why the MikroTik hotspot login page is not showing, and the FAQ near the end of this article answers it in a short form.
2.2 Paid or Valid Codes With No Access Granted
This is the most frustrating group. The user reaches the login page, enters a code that should be valid, and still gets no access. MikroTik hotspot valid voucher no internet complaints come from a failure in the steps that happen after the code is typed: authentication, the RADIUS response, the service flag, or the profile assignment.
The key move is to separate code entry problems from access grant problems. If the page says the username or password is wrong, look at entry and credential status first. If the page accepts the login but the user still cannot browse, the code was probably fine and something after authentication failed, such as a profile that does not allow traffic or a session that never got properly recorded. Ask the user what message they saw, word for word. “Invalid” and “no response from server” send you in very different directions.
2.3 Unexpected Logouts and Short Sessions
Some users log in successfully and then get dropped. MikroTik hotspot frequent disconnects are a sign that something in the session is ending earlier than expected. The usual suspects are session handling, accounting records, timeout behavior, or unstable communication with the server.
Keep the discussion generic at this stage. Ask whether the logout happens when the user is idle, when they move around, or when many people are online. Ask whether the user is always dropped in the same way. A pattern, even a rough one, tells you whether you are chasing a consistent setting or an occasional link problem. You will use that distinction again in section 6.
3. Diagnosing User Authentication Failures
Authentication is the moment the router asks the server to approve a user. When it fails, check the cheapest, most common causes first. That means the user side before the server side: what was typed, what the credential’s status is, and only then what the server said back.
3.1 Wrong Username or Voucher Code Entry
Mistyped input causes more failed logins than most operators expect. Ask the user to clear the fields and enter the code again slowly, without pasting from a message that may have added extra characters or spaces at the start or end.
Watch for characters that look alike. The letter O and the number zero, the letter I and the number one, and a lowercase L are classic confusions. Also check case: some systems treat upper and lower case letters as different characters, and a code typed in the wrong case fails even though every letter is right. Finally, confirm the exact code that was supplied. Look at the original receipt, message, or printed voucher yourself rather than trusting a retyped copy from the customer. If you can see the code in your billing records, compare it character by character with what the user entered.
3.2 Expired or Already Used Credentials
A correctly typed code can still be rejected because of its status. Every credential has a life: unused, active, used up, or expired. The system checks that status during authentication, and a credential outside its valid state is refused no matter how carefully it was entered.
Ask a few simple questions. Has this code been used before, perhaps on another phone or by a friend? Was it already tied to a device? Has its validity period ended? I will not guess at durations here, because they depend on how you defined your packages. What matters is that you check the credential’s record in your billing system and read its status. If the record says the code is spent or expired, the rejection is correct and the fix is a new or renewed credential, not a router change.
3.3 RADIUS Reject Responses and Error Messages
A RADIUS reject is the server’s way of saying “I received your request, I understood it, and the answer is no.” That is different from silence. A reject proves the router and server can talk to each other, which is useful news, because it rules out many connectivity and secret problems.
Read the message the user sees, and read the message in your logs, for its general meaning. Wording about an incorrect user or password points to credentials. Wording about a disabled, expired, or limited account points to account status. Wording about a rule, a policy, or a limit being reached points to server policy. When you do see MikroTik RADIUS authentication failed with no clear reject text, the cause is often not a credential at all. Silence, as opposed to a reject, leads you to the next section, where shared secrets and client settings come under the microscope.
4. Checking RADIUS Shared Secrets and Client Settings
Router and server must agree on a few basic facts before they can trust each other. If any of them differ, authentication fails even when every voucher is perfect. Think of it as a locked door where the key on the router and the lock on the server must be cut the same way. For a wider view of how the whole exchange fits together, see the RADIUS authentication process and keep that picture in mind as you check each setting below. Nothing in this section requires commands, only careful comparison.
4.1 Secret Mismatch Between Router and Server
The Shared Secret is a private password known to both the router and the RADIUS Server. The router uses it to protect each request it sends, and the server uses it to confirm the request really came from a trusted router. If the secrets differ by even a character, the server cannot validate the request, and the typical result is MikroTik RADIUS authentication failed behavior: logins that never succeed while the server logs complain about invalid or unverifiable requests.
A RADIUS shared secret mismatch on MikroTik is easy to cause and hard to see, because the secret is hidden on screen. Compare systematically:
- Identify which server entry the router actually uses, since a router can hold more than one entry and an old one can linger.
- Look for stray spaces at the start or end of the secret, which are invisible but count as characters.
- Check that the server has a client entry matching your router’s address, and that the secret on that entry is the one you intend.
- When in doubt, set the same new secret on both sides at the same time instead of trying to read the old one.
Never paste secrets into tickets, chats, or screenshots. Treat them like any other password.
4.2 Incorrect Server Address and Port Settings
Requests can only be answered if they reach the right place. Check the RADIUS Server address configured in the RADIUS Client settings on the router. A typo in the address, a leftover address from an old server, or an address that is no longer reachable will make every request vanish.
Ports matter as well. RADIUS uses Authentication Port 1812 for login requests and Accounting Port 1813 for session records. The router’s configured ports need to match what the server listens on. If authentication works but accounting does not, or the reverse, a port mismatch for that one function is a good suspect. The pattern is useful: when only usage reports are wrong while logins succeed, look at the accounting side first.
4.3 Timeout and Retry Values That Hide Real Errors
When the router sends a request and gets no answer, it waits, then tries again. Those waiting and repeating habits are the timeout and retry behavior. They are helpful for a brief network hiccup, but they can disguise a real problem. A wrong secret, a wrong address, or a blocked path can all look like a slow network, because in every case the user simply waits and eventually sees a failure.
With MikroTik hotspot RADIUS timeout and retry symptoms, do not respond by only making the router wait longer. Treat repeated timeouts as a signal. Check the secret, check the address, and check connectivity. If a different user logs in successfully right after, the cause may be intermittent. If every attempt times out, the cause is almost certainly consistent, and you should go straight back to configuration comparison.
5. Verifying Hotspot Service Flags and Login Methods
Even with a correct secret and a reachable server, billing breaks if the router does not send hotspot logins to RADIUS in the first place. This section is about MikroTik only: how the Hotspot Server, the RADIUS Client, and your chosen login methods work together.
5.1 Missing Hotspot Service in RADIUS Client Settings
The RADIUS Client on MikroTik RouterOS can be used for several purposes, and each purpose is a service flag. For billed hotspot logins to be processed, the hotspot service must be enabled in the RADIUS Client entry. Review your MikroTik hotspot RADIUS service settings and confirm that the entry you rely on actually includes the hotspot service. Also confirm that the Hotspot Server is set to hand logins to RADIUS rather than checking only local users.
The symptom pattern is distinctive. The server logs show no requests from the router at all, yet users are typing codes and getting refused or, worse, getting in without being billed. If your RADIUS Server never hears from the router while the router is busy with logins, a missing service flag moves to the top of your list. Fixing the flag usually clears the problem immediately, which is why this check is worth doing early.
5.2 Conflicting HTTP PAP, CHAP, and Cookie Login Options
The login method decides how a user’s credentials travel from the login page to the router. PAP sends the password in a simple form, and CHAP uses a challenge so the password is not sent in the clear. Cookie Login lets the router remember a device after a successful login so the user does not need to enter the code again.
The difficulty comes from combining them carelessly. With MikroTik hotspot PAP CHAP cookie login options enabled in a conflicting way, one device may log in smoothly while another keeps failing, or a user may get in once and be refused the next time. Cookie Login can also hide a problem: a device with a stored cookie works, while a brand new device with the same code fails, leading you to blame the code. When results differ between devices or between first and later logins, compare the enabled login options against what your login page and RADIUS Server actually support. Keep the combination simple and consistent, then test with a fresh device that has never logged in.
5.3 Default Profile Assignments That Bypass Billing Rules
A Hotspot User Profile is a bundle of rules attached to a user, such as speed limits and session controls. When a user logs in, the profile tells the router how to treat that session. If the RADIUS response names a profile, that profile applies. If it does not, the router falls back to a default.
An incorrect default is a quiet billing problem. A user may receive a profile that allows more than they paid for, no speed control, or no meaningful session control. Nothing looks broken, which is why it goes unnoticed until revenue or complaints reveal it. Review which profile is assigned by default, confirm that every package you sell maps to a named profile, and confirm the server returns the intended profile for each credential. When a user gets access that does not match their package, look here before suspecting the voucher.
6. Resolving Firewall and Connectivity Blocks Between Router and Server
Now picture the path between MikroTik RouterOS and the RADIUS Server as a road with traffic in both directions. The request travels to the server, and the answer travels back. A break anywhere on that road produces failures that look like bad settings. The goal is to check the path methodically, without commands, and to confirm your router billing platform connection is sound from end to end.
6.1 Blocked Authentication and Accounting Ports
A Firewall Filter rule can quietly drop the traffic RADIUS needs. The general symptom is no server response: the router sends requests, nothing comes back, and timeouts pile up. With MikroTik firewall blocking RADIUS ports, the settings can look perfect while the traffic never arrives.
Review your Firewall Filter rules for anything that blocks or drops traffic between the router and the server, and remember the order of rules matters: an early drop rule can override a later allow rule. Verify that traffic for authentication and accounting is allowed in both directions, meaning requests going out and replies coming back. Also check for firewalls on the server side or at the hosting provider, since a block there looks identical from the router. If you recently changed firewall rules and failures started soon after, that timing is strong evidence.
6.2 Unstable Links and Packet Loss to the Server
Not every failure is a settings error. If the connection to the server is unreliable, some requests get through and some do not. Packet loss means pieces of network traffic disappear on the way, and even small loss can make authentication and accounting fail only part of the time.
Here is how to tell the difference. A consistent configuration error fails the same way every time, for every user, usually from the moment of the change. An intermittent link problem fails unpredictably: one user succeeds, the next fails, then the first fails too. It often gets worse at busy periods or when the internet connection is shared with heavy traffic. Notice whether failures cluster at certain times, and whether the router’s own connection to the internet is steady. If settings compare cleanly and failures still come and go, treat the link as the suspect and talk to your connectivity provider.
6.3 NAT and Routing Paths That Break Server Replies
A reply must find its way home. NAT, short for Network Address Translation, rewrites addresses as traffic passes through a router, and routing decides which path traffic takes. If either is set up in a way that changes the router’s address as the server sees it, or sends the server’s reply down a different path, the answer never reaches the router that asked.
The habit to build is checking the forward path and the return path as a pair. Ask which address the server sees as the source of the router’s requests. Ask whether the server has a client entry for exactly that address, because a NAT rule may be presenting a different one than you expect. Then ask whether the server’s reply has a clear route back. A request that arrives while the reply disappears produces the same timeouts as a blocked port, so keep both directions in mind.
7. Fixing Accounting Gaps and Session Record Mismatches
Authentication decides who gets in. Accounting records what happened afterward, and those records drive usage totals and balances. When records are wrong, customers are billed wrongly even if logins work perfectly. To understand how ended sessions should be handled, read about session expiry handling alongside this section. The core ideas are Start records, Stop records, and duplicate sessions.
7.1 Missing Start Records After Successful Login
An Accounting Start Record is the message the router sends when a session begins. If it never arrives, the session may be active on the router but missing, or unauthenticated-looking, in reports. MikroTik RADIUS accounting missing records of this kind often appear as users who are online but invisible to the billing system.
Always check login success and record creation together. A successful login proves authentication worked. It does not prove accounting did. Compare the router’s list of active users with the sessions your billing system shows. If users appear on the router but not in the records, look at the accounting side of the RADIUS Client settings, the accounting port configuration, and the path to the server. Because accounting uses its own port, authentication can be healthy while accounting is blocked.
7.2 Missing Stop Records After Logout or Timeout
An Accounting Stop Record is the message that closes a session when a user logs out or a limit is reached. If it never arrives, the session stays open in the records, and the system may keep counting time or usage that no longer exists. This is another form of MikroTik RADIUS accounting missing records, and it often shows up as balances that fall for users who left long ago.
Connect this to the general idea of ending sessions. When a Session Timeout is reached, or the user logs out, the router should report the end of the session. If the report is lost because of a blocked path, unstable link, or accounting settings, the server never learns the session ended. Check whether open sessions in your records match who is actually online. Sessions that linger with no matching active user are a strong clue that Stop messages are not arriving.
7.3 Duplicate Sessions That Distort Usage and Balances
A duplicate session means the records show the same user, or the same activity, more than once. Usage then gets counted twice, and balances drop faster than they should. This often follows an earlier gap: when a Stop record was lost and the user logged in again, the old session stays open beside the new one.
Here is how to fix hotspot usage mismatch from duplicate sessions in practical terms:
- Recognize duplicates by looking for the same credential with overlapping sessions in your records, especially where the router shows only an active session.
- Trace the cause by checking whether Stop records were missing earlier, since open stale sessions are the usual source.
- Repair the underlying gap in accounting delivery first, then clean up the stale records.
- Review the records again after a normal busy period to confirm duplicates do not return.
Cleaning records without fixing delivery only hides the symptom, and the duplicates will come back.
8. Correcting Rate Limits and Profile Speed Problems
Billing is not only about who gets in. It is also about what they receive. Speed problems usually trace back to the Hotspot User Profile, its Rate Limit, and any Simple Queue that also touches the same traffic. A Simple Queue is a router rule that controls how much bandwidth a device or group can use. For a broader view of how these controls fit together, see router enforced speed limits. This discussion stays generic, with no speed values, so you can apply it to any package design.
8.1 Speed Limits That Do Not Apply After Login
When MikroTik hotspot rate limit not applying is the complaint, a user is online but runs faster or slower than their package says. Common reasons are a wrong profile assignment, a missing Rate Limit inside the profile, or a conflicting setting elsewhere that overrides it.
Work in plain steps. First confirm which profile the user’s session actually received, not the one you assumed. Next check whether that profile contains a rate limit. Then look for anything else controlling the same traffic, such as a manually created queue, that might win over the profile. If the session received the default profile, go back to section 5.3. If the profile is right and the limit is present, a conflict with another queue is the next suspect.
8.2 User Profiles With Conflicting Bandwidth Settings
Operators often build many profiles over time, and they drift. Profiles meant for different packages may contain overlapping or contradictory bandwidth settings, and users then see unpredictable speeds. MikroTik hotspot user profile speed problems frequently come from this kind of drift rather than from any obvious mistake.
Compare the profiles you assign, side by side, in a plain table you keep for yourself: the package name, the profile it should use, and the limits that profile carries. Look for profiles that should differ but do not, profiles that carry a limit meant for another package, and old profiles nobody remembers creating. Then confirm that each credential really points to the profile you intend. You do not need command knowledge for this, only patience and a tidy list.
8.3 Queue Behavior That Slows the Whole Hotspot
Sometimes the problem is not one user but everyone. When profiles and limits interact poorly, queue behavior can drag the whole Hotspot Server down. A queue that is too broad can treat all users as one group. Limits that stack on top of each other can squeeze traffic far below what any package promises.
Recognize a hotspot wide slowdown by its pattern: many users complain at the same time, speeds feel capped no matter who is testing, and the problem started after a profile or queue change. Trace the slowdown to profile design rather than to the internet service itself. Review how profile limits and Simple Queue entries overlap, remove accidental duplication, and make sure each rule has a clear purpose. A clean, minimal queue design is easier to troubleshoot than a clever one.
9. Preventing Repeat Billing Issues With Logs and Monitoring
Fixing a problem once is good. Never seeing it again is better. Logs and routine checks turn firefighting into prevention, and they help you avoid unpleasant surprises when many users arrive at once. Pair the log review below with real time user monitoring so you can compare what the logs say with who is online right now.
9.1 RADIUS Debug Logs for Repeat Failures
The RADIUS Debug Log records the detailed back and forth between the router and the server. When the same failure keeps recurring, it is your first detailed source. MikroTik RADIUS debug logs show whether requests were sent, whether replies came back, and what kind of reply arrived: accept, reject, or nothing at all.
Use them to answer simple questions. Did the router send the request? Did a reply arrive? If a reply arrived, was it a reject, and why? If no reply arrived, the problem is likely the secret, the address, or the path. Debug logging can be noisy, so turn it on for focused investigation and review it with a specific question in mind, then return to normal logging when you have your answer.
9.2 System Logs for Hotspot and DHCP Events
The System Log on MikroTik RouterOS holds broader context. Entries from the Hotspot Server show login attempts, successes, and failures. Entries from the DHCP Server show whether devices received addresses. Together they explain problems that happen before RADIUS is ever involved, like a device that never got an address or never reached the login page.
When a complaint arrives, match its time to the log. Find the user’s login attempt and see what the Hotspot Server recorded. Find the address assignment and see whether the DHCP Server completed it. This context turns “it did not work” into a clear sequence of events, and it tells you whether to continue into RADIUS details or stay with redirect and address assignment.
9.3 Routine Checks Before Peak Usage Periods
A short routine before your busy periods catches most problems while they are still small. Make it a repeatable habit and walk through the same list each time:
- Secrets: confirm the router and server still agree.
- Service flags: confirm the hotspot service remains enabled in the RADIUS Client settings.
- Connectivity: confirm the server is reachable and the link is steady.
- Profiles: confirm each package still maps to the intended profile and limits.
- Accounting health: confirm Start and Stop records are arriving and no stale sessions linger.
- Logs: scan recent System Log and RADIUS Debug Log entries for repeated errors.
Keep brief notes after each check. Over time those notes show you what changes before failures happen, which is the real prize of monitoring.
10. FAQ
10.1 Why does the hotspot login page fail to appear?
The page cannot show if the device never receives an address, if the Hotspot Server is not active on that network, or if the redirect is interrupted by connectivity trouble. Check whether the device received an address from the DHCP Server, try a simple website address in the browser, and see whether other devices are affected. If many are affected, check the router. If one device is affected, check that device.
10.2 Why is a valid voucher code rejected at login?
Start with entry: a lookalike character, wrong case, or a stray space can break an otherwise correct code. Then check status, since an expired or already used credential is rejected even when typed perfectly. If both look fine, read the RADIUS reject message to learn whether the cause is credentials, account status, or server policy. These are the usual reasons a valid hotspot voucher code is rejected.
10.3 Why does access stay blocked after successful payment?
Payment is only one step. Access needs authentication to succeed, the right profile to be assigned, the hotspot service flag to be enabled, and accounting to be confirmed. If any link in that chain is incomplete, a hotspot blocks access after payment even though the money arrived. Check the credential’s status first, then the RADIUS response, then the service flag and profile assignment.
10.4 Why do users get disconnected without warning?
Short sessions usually trace back to session handling, accounting gaps, or unstable communication with the server. A missing or mistimed record can make the system end or misjudge a session, and an unreliable link can interrupt the exchange that keeps it valid. This is why MikroTik hotspot disconnects users after short sessions in so many setups. Look for patterns in time and affected users, then compare against your accounting records and connectivity.
10.5 Why does usage reporting differ from actual session time?
Reports depend on Start and Stop records. If a Start record is missing, a session may not appear properly. If a Stop record is missing, a session stays open and keeps counting. Duplicate sessions count the same activity more than once. Each of these makes reported usage differ from what users actually did.
10.6 When should RADIUS logs be checked first?
Check them first for repeat failures, for rejects you cannot explain, for timeouts, and for accounting mismatches. If a problem happens once, a quick look at the user’s entry and credential status may be enough. When it happens again, the RADIUS logs are the best detailed source, and they are the clearest answer to when to check RADIUS logs first for hotspot billing failures.