IPTV Won't Connect: Read the Error Before You Change Anything
The three values, and where they come from
An Xtream line is three things: a host with a port, a username, and a password. Your provider sends them after purchase, usually as a message. Everything your player does is built from those three.
The format trap catches people first. Some apps want the whole thing as http://host:port in one field. Some want a bare hostname in one field and the port in another. Some branded apps want a short code or activation word instead of a URL. Use exactly what your provider sent, in the shape the app is asking for.
One rule that saves whole evenings: never copy a host from a forum, or from a friend on the same service. Providers routinely put different customers on different hosts, so someone else's working address is simply wrong for your line — and it fails in a way that looks like your account is broken.
This is standard across Xtream-compatible providers — Strong 8K and Trex IPTV are two — which sell subscriptions by duration, send you the same host, username and password, offer a MAC and portal option for MAG boxes, and handle support over WhatsApp.
What your player is actually calling
Same host, same credentials, three endpoints:
player_api.php— your account status and channel data, as JSON.get.php?username=USER&password=PASS&type=m3u_plus— the playlist.xmltv.php— the TV guide.
That is the whole thing, as far as you need to care. It means you can test your line without the player at all.
Test it in a browser
On a phone or laptop, open:
http://host:port/player_api.php?username=USER&password=PASS
Two things to know before you press enter.
- This address contains your password in clear text, and so does the reply. Treat the tab the way you would treat the original message from your provider: no screenshots, nothing pasted wholesale into a chat, and clear it from the history of any shared device.
- Check that the address bar still says
http. Chrome and Edge with HTTPS-First mode enabled, and Safari, will quietly upgrade the address tohttps. On a port that is not serving TLS that produces a hang and a timeout, which is exactly the outcome you are about to read as "nothing is answering". If the address was rewritten, dismiss the upgrade or turn HTTPS-only mode off, and run it again.
Four outcomes, and each one points somewhere different:
- A block of JSON containing
user_info. Your account and the network path are both fine. The fault is in the player, or in how the details were typed into it. {"user_info":{"auth":0}}. The server answered and rejected the credentials. The path works; the username or password is wrong, or the account is disabled.- The page hangs and times out. Nothing is answering on that host and port — a path, host or port problem, not a credentials one. Confirm the address bar did not upgrade you to
httpsbefore you believe this one. - "Server IP address could not be found" or "unable to resolve host". That is DNS. The name never turned into an address, so the request never left. See below.
Reading user_info line by line
status— Active, Expired, Disabled or Banned. Anything but Active is an account matter, not a settings matter.exp_date— a Unix timestamp: seconds since 1 January 1970 UTC. Paste it into any "unix timestamp converter" to read it as a date. A recently passed date is one of several explanations for an "it worked yesterday" case — the error table below lists others.is_trial—1means a trial line. How long a trial runs is set by the provider, so readexp_dateabove for its actual end.max_connectionsandactive_cons— how many devices may stream at once, and how many are streaming now. If they are equal, a new device is refused.allowed_output_formats— typicallym3u8,ts,rtmp. If your player is forcing a format that is not listed, it will fail on every channel while the account is perfectly healthy.
One field is not in that list on purpose. The block also repeats your password in plain text. That is why the four values above are the ones to quote when you ask for help, and the block as a whole is not something to paste anywhere.
Error by error
| What you see | What it means | Next step |
|---|---|---|
Invalid username or password, or auth:0 | Server reached, credentials rejected | Re-paste both values from the original message; check for a trailing space |
| Account expired | exp_date has passed | Renew; nothing on the device will help |
| Maximum connections reached | Another device is streaming | Stop the others, wait a few minutes for the session to time out |
| Connection timed out | Nothing answering on that host and port | Verify the port, check the browser did not upgrade you to https, retest on mobile data |
| Unable to resolve host | DNS never returned an address | Change resolver, or test on mobile data |
| Logs in, channel list empty | Playlist fetch failed or categories are hidden | Refresh the playlist; check the app's group filters; if get.php is empty in a browser, it is provider-side |
| One stream 404s, everything else plays | That single channel is down | Report the channel name |
The typo class of failure
Typing is a common cause of "invalid credentials", and it is the cheapest one to rule out. A trailing space on a pasted password. Lowercase l against the digit 1. Capital O against zero. A mobile keyboard capitalising the first letter of the username. Autocorrect quietly rewriting part of the host.
Paste rather than type, every time. Turn off auto-capitalisation and autocorrect in the field if the app lets you, and retype nothing you can copy.
http, https, and the port
The port is part of the address, not an optional extra. You will commonly see 80, 8080, 8000, 2082, 2086, 2095 and 25461. Getting the port wrong produces a timeout, which looks exactly like a dead server.
Forcing https onto a port that is not serving TLS does not give you a certificate warning — the connection simply fails, because there is no TLS handshake to warn about. This is why "just try https" so often looks like proof that the server is down when it proves nothing at all, and it is also why a browser that upgrades your test URL on its own can invent the same false result. Use the scheme your provider gave you.
When it is DNS
DNS turns the host name into an address. When it fails you get "unable to resolve host", or a stale answer pointing at a server that stopped responding after the provider moved hosts.
Test it: try the same host on mobile data, which uses a different resolver. If it works there and not on Wi-Fi, your router's resolver is the problem. Then set a public resolver — 1.1.1.1, 8.8.8.8 or 9.9.9.9 — on the device or on the router, and retry.
To be clear about which fault this fixes. It fixes a resolver that is failing outright or holding a stale record — your own resolver is the odd one out, and every other network resolves the host correctly. If instead the host resolves nowhere on your ISP and fine everywhere else, and your ISP is blocking it deliberately, that is a matter between you and your ISP, and this guide stops there.
"I just bought it and nothing works"
How your line is delivered, and how long that takes, is your provider's business and not something this guide can promise on their behalf. Before assuming a fault: check the message actually arrived, check the number or address it was sent to, and read it against what your app is asking for — a line delivered correctly and typed in wrongly looks identical to one that never arrived. If nothing has arrived, that is a support message, not a settings problem.
MAG and portal boxes fail differently
A MAG or portal box does not use a username and password. It uses a portal URL plus a MAC address registered on the provider's side. Infomir's MAG hardware uses the 00:1A:79 range, but other portal boxes and set-top emulator apps have prefixes of their own — a MAC that does not start with 00:1A:79 is not evidence of anything. What matters is that the MAC shown on the box matches the one registered against your line.
"Portal not found" or "no link found" points at one of two things: the MAC is not registered, or the portal path is wrong. Neither is fixable from the box, so this one goes straight to support with your MAC address.
Stop here and message support
If the browser test did not resolve it, send five lines. Never send your password, and never paste the whole user_info block — it carries your password in clear text.
- Your username. Your password is never needed and should never be sent.
- The exact error text your player shows.
- From
player_api.php, four values only:status,exp_date,max_connectionsandactive_cons. Those four are safe to share. Nothing else from that response is. - Your player and your device.
- Whether it behaved the same on mobile data.
Then read the buffering guide if it connects but stalls, or the EPG guide if it plays but the guide is empty.
If you are choosing a provider rather than fixing one, the same operator runs several storefronts with different emphases: Strong 8K and Trex IPTV lead on activation speed, while Strong 8K and Trex IPTV lead on plans and the player app. They are ours — see how this site is funded.