`111.90.150.2044` is not a valid standard IPv4 address as written. Under the IPv4 grammar in RFC 3986, a dotted-decimal IPv4 address contains four decimal components, each ranging from 0 to 255. In this case, the final component is `2044`, which is outside that range.
That answers the main question, but it does not reveal what the string was intended to mean. It could be a typo, malformed log entry, formatting error, or some other piece of text. There is no verified basis for silently changing it into another IP address or treating it as evidence of malware.
Why 111.90.150.2044 is invalid as IPv4
The string divides into four dotted components:
`111 . 90 . 150 . 2044`
The first three values fall within IPv4’s permitted range. The fourth does not.
RFC 3986 defines an IPv4 address as four decimal values in the range 0–255. That makes `2044` the specific part that prevents `111.90.150.2044` from being a valid IPv4 literal.
This distinction matters because some pages describe the string as a “hybrid IP address.” That is not a standard category established by the IPv4 grammar. A more accurate description is a malformed IPv4-looking string.
It can still appear online as text, in a database, in a search index, or inside a malformed log field. Saying it is invalid IPv4 does not mean the character sequence itself cannot appear on the internet.
Could 2044 be a port number?
Possibly, but there is no evidence that this particular string was intended that way.
A network port normally follows a host after a colon in URI syntax. For example:
`111.90.150.204:2044`
That is structurally different from:
`111.90.150.2044`
The IANA Service Name and Transport Protocol Port Number Registry lists port `2044` for both TCP and UDP under the service name `rimsl`. So claims that 2044 is inherently an unregistered or “non-standard” port are incorrect.
But the registration does not prove that `.2044` was supposed to mean `:2044`. IANA also cautions that traffic using a registered port does not necessarily correspond to the service assigned to that number.
Without the original log, URL, configuration, or application output, the intended interpretation remains unknown.
Is 111.90.150.204 the correct address?
There is no basis for saying that it is.
`111.90.150.204` is a valid IPv4 address, but it is a different value. Removing the final `4` from the malformed string would be a guess, not a verified correction.
As of September 30, 2026, current routing information for that separate address associates it with AS45839 and Shinjiru Technology Sdn Bhd. IPinfo’s record for 111.90.150.204 reports that network association, while Hurricane Electric’s BGP Toolkit provides a separate routing view for the same address.
Those details apply only to `111.90.150.204`. They should not be transferred to `111.90.150.2044`.
The same caution applies to geolocation. IP intelligence may place a valid address in a general region, but that does not establish the physical location of a particular user, device, or server.
Is 111.90.150.2044 a security threat?
The malformed string alone does not prove malicious activity.
Some web pages have connected it with malware, botnets, phishing, deliberate obfuscation, or unusual network behavior. Those claims go beyond what the underlying syntax establishes. An invalid IPv4-looking value may deserve investigation when it appears in a security log, but malformed formatting is not itself evidence of an attack.
Likewise, a strange-looking numeric string should not be used as a reason to block a nearby real address or an entire network range. Doing so could affect unrelated systems.
The useful distinction is simple: an invalid address format is a data-quality or interpretation problem until additional event-specific evidence shows otherwise.
What to check if it appears in a log
If `111.90.150.2044` appears in a server, firewall, SIEM, application, or access log, preserve the original entry before trying to correct it.
Check:
- the raw field in which the value appeared;
- the characters immediately before and after it;
- whether a colon or another delimiter may have been lost;
- the actual source and destination IP fields;
- any separate source or destination port fields;
- whether an application, parser, export tool, or copy-and-paste step could have altered the value;
- the timestamp and surrounding events.
The context may reveal whether the string was malformed input, a logging problem, a concatenated value, or simply unrelated text. What it does not justify is automatically converting `111.90.150.2044` into a different IP address.
The safest conclusion is therefore narrow but firm: `111.90.150.2044` is not a valid standard IPv4 address, and its intended meaning cannot be recovered reliably without the original context.
