AS142207 Keeps WJY Visible in the Registry After Its Public Route Goes Quiet

Summary

• APNIC RDAP records AS142207 as active under WJY-AS-AP, country code CN, with WJY (Shanghai) Technology Co., Ltd. as the exact registrant.
• That registration establishes an administrative number-resource identity; it does not establish facilities, customers, licensing, contracts, ownership structure or current service delivery.
• RIPEstat reported announced=false at 2 August 2026 08:00 UTC, with no visible IPv4 or IPv6 prefixes and no observed neighbours.
• In the same dated response, none of the 327 sampled IPv4 RIS peers or 321 sampled IPv6 RIS peers saw AS142207.
• RIPEstat records first visibility on 2 February 2026 16:00 UTC and last visibility on 8 July 2026 16:00 UTC, when the last-seen prefix was 151.158.14.0/23.
• The announced-prefixes result was empty for its 19 July to 2 August 2026 query window, reinforcing the narrow finding of no current announcement in that captured view.
• PeeringDB preserves an operator-maintained identity and declared interconnection posture for AS142207, but it does not measure routes, traffic, customers, sessions or delivered capacity.
• The website linked from PeeringDB names WJY (Hong Kong) Limited rather than the Shanghai registrant, leaving the relationship between the two legal names unresolved.

Editorial illustration of an administrative network identity remaining visible while a dated public routing path is quiet; it does not depict a WJY facility, outage, customer network or measured service outcome.

A number remains attached to an exact name

The clearest fact about AS142207 is administrative. APNIC RDAP records the autonomous-system number under the name WJY-AS-AP, assigns country code CN, marks the record active and links it to registrant handle ORG-WTCL6-AP. The associated registrant object gives the full legal name WJY (Shanghai) Technology Co., Ltd. The indexed BTW directory entry uses that same company name and binds the same company profile to AS142207.

That agreement matters because it fixes the subject at a level more exact than a brand, website or similar company name. The relevant directory entity is the Shanghai company. The relevant number resource is AS142207. The public registrant handle supplies a traceable link between the autonomous-system record and the named registrant. No broader corporate group needs to be inferred to establish that registry identity.

An active registry record answers a bounded coordination question: which organisation is recorded against this number resource in the APNIC system? It preserves a recognisable identifier and an accountable registrant name even when other evidence is sparse. It also allows future observations to be compared against the same number without relying on branding or a mutable website description.

The word “active” must remain inside that administrative context. It does not show that AS142207 was exporting a route at a particular moment. It does not show that packets were flowing, that a service was available or that any customer depended on the network. Nor does it prove beneficial ownership, licences, buildings, equipment, contracts or corporate control. A registry can accurately identify the holder recorded for a number resource without answering any of those separate questions.

This is why the exact name is valuable but not expansive. WJY (Shanghai) Technology Co., Ltd. is visible as the registered identity attached to AS142207. The record creates a stable starting point for examining the network’s public routing state. It does not fill the operational and commercial gaps that appear after that starting point.

Registration and routing answer different questions

A registered autonomous-system number and an observed route are related, but they are not interchangeable. The registration provides a durable administrative reference. A routing observation asks whether the number appeared in the public routing data visible to a particular collection system at a particular time. One can persist while the other is absent from view.

That separation is especially important for AS142207 because the two layers point in different directions without actually contradicting each other. APNIC continues to show an active record for WJY (Shanghai) Technology Co., Ltd. RIPEstat, meanwhile, reports that the autonomous system was not announced in its dated 2 August view. The registry is not making a claim that a route was visible then, and the routing result is not cancelling the registration. Each describes a different state.

Administrative continuity can survive a change in observed routing. A number can remain uniquely associated with a registrant even if no prefix is visible from it in a later capture. That continuity keeps the identity available for coordination, comparison and future verification. It says who remains named in the record, not what the network is presently doing.

Observed routing carries a different kind of authority. It tests the active public signal rather than the persistence of the administrative entry. When a route collector reports no visible prefixes, no observed neighbours and no sampled peers seeing the autonomous system, that is direct evidence about the collector’s captured view. It is more relevant to the question “was this AS visible here at this time?” than a registry status or operator declaration could be.

The reverse is equally true. The routing capture is not the better source for the legal name recorded against the number. It can report a holder string and routing state, but APNIC RDAP supplies the direct registry binding between AS142207, WJY-AS-AP, the CN country code, the active status, the registrant handle and the exact Shanghai company name.

Treating one layer as a substitute for the other would produce two opposite errors. Reading an active registration as proof of a running public route would inflate an administrative fact into an operational one. Reading a quiet routing capture as proof that the company ceased operating would inflate a dated observation into a claim about an entire business. The disciplined conclusion sits between those errors: the registered identity persists, while the public route is absent from the specified RIPEstat view.

The routing view at one fixed time

RIPEstat’s AS overview reported announced=false for AS142207 at 2 August 2026 08:00 UTC. Its routing-status response for the same autonomous system recorded zero visible IPv4 prefixes, zero visible IPv6 prefixes and zero observed neighbours. It also reported that none of the sampled RIS peers saw the AS: zero of 327 for IPv4 and zero of 321 for IPv6.

RIPEstat field	Dated result
Observation time	2 August 2026 08:00 UTC
Announced	false
Visible IPv4 prefixes	0
Visible IPv6 prefixes	0
Observed neighbours	0
IPv4 RIS peer visibility	0 of 327
IPv6 RIS peer visibility	0 of 321

Taken together, those values form a coherent captured state. The result is not merely that one current-prefix field happened to be empty. The overview’s announcement flag, both address-family prefix counts, the neighbour count and the sampled-peer visibility all point to the same narrow outcome: RIPEstat did not see AS142207 participating in the public routing view represented by that response at that time.

The sampled-peer figures add useful scale to the observation. Zero of 327 IPv4 peers and zero of 321 IPv6 peers is stronger within that dataset than silence from a single unspecified vantage point. The figures show that the absence extended across every sampled RIS peer counted in the response for both address families. They make the captured non-visibility specific and testable.

They do not make it universal. The denominators define the sampled peer population in that response, not every possible observation point on the Internet. “Zero of 327” means exactly that none of those 327 IPv4 peers saw the autonomous system in the relevant view. It does not mean that every routing system everywhere was queried. The same boundary applies to the 321 IPv6 peers.

The zero neighbour count must be read just as carefully. It means RIPEstat observed no neighbours for AS142207 in the captured routing state. It does not prove that the Shanghai company had no agreement, configuration, private connection or unobserved relationship of any kind. It cannot identify why the public signal was absent, and it cannot convert the absence of an observed adjacency into evidence that no operational arrangement existed outside the view.

The timestamp prevents the result from floating free of time. It anchors the finding to 2 August 2026 at 08:00 UTC. A later observation could differ. An earlier observation did differ, because the same routing-status response contains first-seen and last-seen fields. The useful claim is therefore not that AS142207 can never be seen, but that it was not visible in this dated RIPEstat capture.

Strong zeros, bounded conclusions

Several zero values can be powerful evidence without being proof of a shutdown. Their strength comes from agreement across fields. Their boundary comes from the limits of what those fields measure.

Within the RIPEstat response, the zeros are unambiguous. No IPv4 prefix was visible. No IPv6 prefix was visible. No neighbour was observed. No sampled IPv4 or IPv6 RIS peer saw the autonomous system. The announced flag was false. Any description suggesting that the same response showed a currently visible public route would conflict with the data.

The zeros also resist an easy attempt to replace routing evidence with declared capacity. A separate record may describe an intended network posture or contain nonzero capacity fields, but that does not change what the RIPEstat collectors reported. Declared ability, administrative entitlement and observed announcement are different variables. In the dated routing view, the observed values were zero regardless of what appeared in PeeringDB.

Yet the same zeros do not reveal a cause. They do not distinguish among possible explanations, and the frozen records do not provide an event account. There is no basis here for describing an outage, a deliberate withdrawal, a technical failure, a commercial decision or a business closure. Selecting one of those explanations would require evidence that connects the visible routing state to an actual event or decision.

Nor do the zeros establish customer impact. The records identify no customers and provide no customer measurements. Without a defined service, an affected party, a relevant time interval and direct operational evidence, there is no support for saying that anyone lost access or experienced degraded performance. The absence of an AS from the sampled public routing view is an infrastructure observation, not an automatic service-impact report.

Universal absence is also beyond reach. RIPEstat provides a collected view with stated peer counts. Its result supports “not visible to the sampled peers in the dated response,” not “absent from every collector and every routing context.” Private connectivity and otherwise unobserved paths are outside the conclusion. The evidence does not show them, but failure to show them is not proof that they did not exist.

A narrow statement is therefore more informative than a dramatic one. At the timestamp recorded by RIPEstat, AS142207 had no visible IPv4 or IPv6 prefixes, no observed neighbours and no sampled RIS-peer visibility in that response. That can be repeated, challenged with another dated observation and revised if the data changes. “WJY shut down” cannot be derived from the same fields and would not carry the same evidentiary discipline.

A short observed routing chronology

The routing-status response adds two historical markers. It records AS142207 as first seen at 2 February 2026 16:00 UTC and last seen at 8 July 2026 16:00 UTC. The prefix associated with the last-seen field is 151.158.14.0/23.

Historical field	RIPEstat value
First seen	2 February 2026 16:00 UTC
Last seen	8 July 2026 16:00 UTC
Last-seen prefix	151.158.14.0/23

These fields establish an observed sequence inside RIPEstat’s record. The autonomous system was visible by the first-seen timestamp. It was visible at the last-seen timestamp in association with the stated prefix. By the 2 August observation, RIPEstat reported announced=false and no current visible prefixes.

The chronology supports the title’s description of a public route going quiet, provided “quiet” remains tied to the RIPEstat view. There was an observed route state, followed by a last recorded sighting, followed by a later captured state with no visible announcement. That is a genuine change in the available routing evidence.

The first-seen field does not prove that no route existed before 2 February. It marks the beginning of visibility represented by the response, not necessarily the beginning of the network’s configuration, registration or operation. There is no basis for turning that timestamp into a company launch date or the start of commercial service.

The last-seen field has a similar limit. It identifies the latest visibility recorded in that response; it does not, by itself, identify the instant or cause of a withdrawal. It cannot show whether the change was planned, accidental, temporary or consequential. It also cannot establish that no other observer saw anything after that time.

The prefix 151.158.14.0/23 belongs only to the bounded historical statement available here: it was the last-seen prefix in the RIPEstat routing-status response. No ownership, customer use, traffic level or physical delivery claim follows from that field. It is evidence of a previously observed routing association, not a map of what the prefix carried.

A future appearance would not make the dated zeros erroneous. It would establish a later state. The chronology is therefore open rather than final: first seen, last seen, quiet at the query time, and capable of being tested again.

The empty announced-prefix window

RIPEstat’s announced-prefixes endpoint returned an empty current list for a query window running from 19 July through 2 August 2026. This result complements the point-in-time routing-status response. No announced prefix appears in that endpoint’s output for the specified interval.

The window matters because it extends the observation beyond a single timestamp while remaining explicitly bounded. It supports the conclusion that the endpoint did not return a current announcement during the 19 July to 2 August query range. Combined with the 8 July last-seen field, it creates a consistent sequence: a last recorded prefix sighting, followed by an empty later query window, followed by the 2 August announced=false state.

An empty list does not identify an event. It contains no explanation for the absence and no statement about business condition. It cannot show who made a routing change, whether a configuration remained available elsewhere or whether any service depended on the route. It is a result about entries returned by that endpoint for that window.

The endpoint also cannot carry an unlimited claim beyond its dates. It says nothing by itself about periods before 19 July, and it cannot predict what happened after 2 August. If a later query returns a prefix, the later result would mark a changed observed state rather than a contradiction of the earlier empty interval.

For monitoring, the value of the empty response lies in its repeatability. The same resource can be queried again, and a nonempty return would be a clearly falsifying change to the current quiet-state description. The test is simple: does the endpoint continue to return no announced prefixes for AS142207, or does a prefix reappear?

PeeringDB preserves a declared network posture

PeeringDB provides a third view of AS142207. Its operator-maintained network record, network id 41314, names WJY (Shanghai) Technology Co., Ltd., associates it with AS142207 and lists the routing-policy identifier AS-WJY. It classifies the network as Cable/DSL/ISP, gives its scope as global and records an open general peering policy. The entry links to wjy.me and was created and updated in January 2026.

This record corroborates an operator-declared network identity. The company name and AS number align with the APNIC registration, while AS-WJY provides an additional network-facing label. The type, scope and policy fields show how the record presents the network’s intended posture in that database.

“Operator-maintained” is the essential qualifier. PeeringDB is recording declarations supplied for the network entry. The fields are useful for identity and stated interconnection orientation, but they do not independently observe a BGP announcement. An open general peering policy does not prove that a session was active on 2 August or that any particular network had a reciprocal relationship with AS142207.

The global scope field likewise cannot be converted into service coverage. It describes the scope declared in the record, not a measurement of reachable markets, facilities, routes or users. The Cable/DSL/ISP classification is a database type, not evidence of subscriber numbers, access speeds or an active retail footprint.

The PeeringDB entry and RIPEstat capture can therefore coexist without conflict. One preserves a declared identity and posture. The other reports what was visible to its sampled routing view at a later dated moment. PeeringDB does not overrule the announced=false result, and RIPEstat does not erase the operator-maintained record.

This distinction prevents a subtle but consequential substitution. A network profile can remain present after an observed route becomes quiet. Its presence may aid identification if the route returns, because the AS number, network name and declared policy remain available for comparison. But the profile itself is not running-code evidence. It cannot show that a route was accepted, propagated or carrying traffic.

The January creation and update timing also belongs inside a limited claim. It shows that the record’s documented lifecycle occurred in that month. It does not prove that every field remained operationally accurate in August. A later routing measurement has greater relevance to August route visibility, while the PeeringDB entry remains relevant to the identity and posture the operator had recorded.

Why 100 and 1000 are not observed routes

PeeringDB lists declared IPv4 and IPv6 prefix-capacity fields of 100 and 1000. Those values may look operational because they are numerical, but their meaning remains declarative. They are not the counts of prefixes that RIPEstat observed.

The contrast is direct. PeeringDB contains nonzero declared capacity values. RIPEstat reported zero visible IPv4 prefixes and zero visible IPv6 prefixes at the dated query time. There is no mathematical inconsistency because the fields answer different questions. A declared capacity field is not a collector’s count of current announcements.

The values cannot be used as traffic indicators. They reveal no packet volume, utilisation or customer load. They do not show that 100 IPv4 prefixes or 1000 IPv6 prefixes were allocated, configured, announced, accepted or in use. They do not define a delivered capacity and cannot be converted into bandwidth.

Nor do they establish customer numbers or service scale. Prefix capacity is not a subscriber count, a contract count or a measure of market presence. Treating it as one would add a commercial meaning that the record does not supply.

The figures also say nothing about physical infrastructure. They do not identify buildings, data centres, routers, fibre paths, cables or geographic locations. A large declarative number does not become evidence of a large physical network merely because it appears next to an autonomous-system record.

For the question of current public visibility, the RIPEstat zeros remain the relevant measurement. For the question of what the PeeringDB entry declares, the 100 and 1000 values can be reported with attribution. Keeping both statements intact preserves a useful tension: the operator-maintained profile expresses a nonzero planned or declared capacity, while the dated collector response sees no current announcement. The tension is a monitoring question, not a licence to invent a cause.

One link crosses two legal names

PeeringDB links the AS142207 network entry to wjy.me. The website, however, names WJY (Hong Kong) Limited. APNIC names WJY (Shanghai) Technology Co., Ltd. as the registrant of AS142207. The legal names and jurisdictions are not exact matches.

The website describes LIR, cloud, colocation, hosting and IaaS services under the Hong Kong company name. Those descriptions can establish how that website presents WJY (Hong Kong) Limited. They cannot automatically be assigned to the Shanghai registrant merely because PeeringDB links the AS record to the site.

APNIC contact information uses a related wjy.cn domain, which adds another connection among the recorded identifiers. That domain relationship may help explain why the records appear associated. It still does not prove legal equivalence, shared ownership or a parent-subsidiary structure.

The careful identity chain therefore contains both a strong binding and an unresolved boundary. The strong binding runs from AS142207 to the APNIC registrant handle and then to the exact Shanghai company name. The unresolved boundary begins where the operator-maintained network record points to a website naming the Hong Kong company.

Collapsing the boundary would create unsupported claims in several directions. It could assign the Hong Kong company’s service descriptions to the Shanghai registrant. It could imply that the Shanghai company controlled any location, facility or capacity described on the site. It could also imply corporate ownership or group structure that none of the frozen records establishes.

The opposite response—ignoring the website entirely—would lose an important identity signal. PeeringDB deliberately associates the network record with that site, and the site presents a related WJY-branded operator description. The relevant conclusion is not that the link is meaningless, but that its legal significance is unresolved.

A stronger corporate claim would require evidence directly connecting the two legal entities. The available names, domains and database links are insufficient for that purpose. Until such evidence appears, the website should be attributed to WJY (Hong Kong) Limited and the AS registration to WJY (Shanghai) Technology Co., Ltd.

This legal-name discipline also protects the routing conclusion from overreach. Even if the Hong Kong site describes an active service portfolio, that does not refute the RIPEstat result for AS142207. Conversely, the quiet AS142207 view does not establish anything about the availability or condition of services described by the Hong Kong company. The two propositions concern different legal and operational subjects unless their relationship can be proved.

Registry continuity versus running continuity

AS142207 remains legible as a network identity because the registry record persists. Its number, registry name, country code, status, registrant handle and exact Shanghai registrant name form an administrative chain. PeeringDB adds a compatible operator-maintained network name, AS-set label, type, scope and policy declaration. Together, those records preserve context.

Running continuity demands different evidence. For the public routing layer, the relevant evidence is whether the autonomous system and its prefixes are visible in current observations. At 2 August 2026 08:00 UTC, RIPEstat answered no. Its peer counts, prefix counts, neighbour count and announcement flag all support that result within the captured view.

The distinction is not merely semantic. Number-resource records support uniqueness and accountability. They allow an AS number to remain associated with a registrant rather than becoming an unexplained numerical reference. Routing observations test whether that identity is presently manifest in the public system being measured. Operational continuity cannot be inferred solely from the survival of the record.

The registry is therefore a ledger, not a live network monitor. It can remain correct about who is registered even when a route is not visible. Its active status should not be treated as a heartbeat for routers, services or commercial operations.

RIPEstat is a running-state observation, but it is not a corporate registry or a complete operational history. Its quiet result cannot cancel the recorded registrant, determine legal ownership or explain the business context. It reports the public signal visible through its collection view.

PeeringDB occupies a third position. It is neither the authoritative APNIC registrant binding nor the dated route observation. It preserves what the network entry declares about identity and interconnection posture. That makes it valuable corroboration, especially when its company name and AS number align with APNIC, but it remains a declaration rather than a measurement.

The three roles can be stated cleanly:

Record	What it establishes	What it does not establish
APNIC RDAP	Registered AS identity and exact registrant name	Current route, service delivery, ownership structure or physical footprint
RIPEstat	Dated visibility in the captured routing view	Universal absence, cause, outage, customer impact or corporate condition
PeeringDB	Operator-maintained identity and declared posture	Active sessions, contracts, traffic, delivered capacity or current announcements

This division of labour makes the evidence more useful, not less. The records need not be forced into a single verdict about whether the company is “active.” Activity is too broad unless the layer is specified. The APNIC record is active administratively. The PeeringDB profile remains present as an operator-maintained declaration. The RIPEstat public routing view is quiet at the recorded time.

A future route announcement would change the running-state finding without necessarily changing the registry. A registry update could change the named administrative identity without proving any route change. A PeeringDB update could alter the declared posture without demonstrating a live session. Each layer needs its own timestamp and its own standard of proof.